From ivazquez at ivazquez.net Wed Feb 1 00:05:53 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 31 Jan 2006 19:05:53 -0500 Subject: Make hardlinking kernel-devel optional In-Reply-To: <20060131222114.GD29937@redhat.com> References: <20060131194417.6d7e411e@dhcp05.addix.net> <20060131222114.GD29937@redhat.com> Message-ID: <1138752353.24298.6.camel@ignacio.lan> On Tue, 2006-01-31 at 17:21 -0500, Dave Jones wrote: > On Tue, Jan 31, 2006 at 07:44:17PM +0100, Ralf Ertzinger wrote: > > Hi. > > > > I't like to request to make the hardlink stage kernel-devel does on every > > install optional. It takes a damn lot of time on my not-too-fast machines, > > I do not exactly care about the saved disk space, and given the rate of > > kernel changes in rawhide there are a lot of wasted CPU cycles there. > > only if you have a huge number of kernels installed, which shouldn't be the case. Or if you build kernel modules against multiple kernel VR's. > > There is a /etc/sysconfig/kernel, how about dropping a "HARDLINK=yes/no" > > there? > > It would mean adding parsing to the kernel spec file, which I'm not entirely > enthusiastic about, especially for something that isn't the common case. %post [ -f /etc/sysconfig/kernel ] && . /etc/sysconfig/kernel if [ "$HARDLINK" != "no" -a -x /usr/sbin/hardlink ] ; then pushd /usr/src/kernels/2.6.15-1.1823_FC4-i686 > /dev/null /usr/bin/find . -type f | while read f; do hardlink -c /usr/src/kernels/*FC*/$f $f ; done popd > /dev/null fi -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From davej at redhat.com Wed Feb 1 00:25:34 2006 From: davej at redhat.com (Dave Jones) Date: Tue, 31 Jan 2006 19:25:34 -0500 Subject: Make hardlinking kernel-devel optional In-Reply-To: <1138752353.24298.6.camel@ignacio.lan> References: <20060131194417.6d7e411e@dhcp05.addix.net> <20060131222114.GD29937@redhat.com> <1138752353.24298.6.camel@ignacio.lan> Message-ID: <20060201002534.GO16557@redhat.com> On Tue, Jan 31, 2006 at 07:05:53PM -0500, Ignacio Vazquez-Abrams wrote: > On Tue, 2006-01-31 at 17:21 -0500, Dave Jones wrote: > > On Tue, Jan 31, 2006 at 07:44:17PM +0100, Ralf Ertzinger wrote: > > > Hi. > > > > > > I't like to request to make the hardlink stage kernel-devel does on every > > > install optional. It takes a damn lot of time on my not-too-fast machines, > > > I do not exactly care about the saved disk space, and given the rate of > > > kernel changes in rawhide there are a lot of wasted CPU cycles there. > > > > only if you have a huge number of kernels installed, which shouldn't be the case. > > Or if you build kernel modules against multiple kernel VR's. > > > > There is a /etc/sysconfig/kernel, how about dropping a "HARDLINK=yes/no" > > > there? > > > > It would mean adding parsing to the kernel spec file, which I'm not entirely > > enthusiastic about, especially for something that isn't the common case. > > %post > [ -f /etc/sysconfig/kernel ] && . /etc/sysconfig/kernel > if [ "$HARDLINK" != "no" -a -x /usr/sbin/hardlink ] ; then > pushd /usr/src/kernels/2.6.15-1.1823_FC4-i686 > /dev/null > /usr/bin/find . -type f | while read f; do hardlink > -c /usr/src/kernels/*FC*/$f $f ; done > popd > /dev/null > fi Removing the Prereq: /usr/sbin/hardlink from the spec (which I just did in CVS) should have the effect that you can now rpm -e hardlink, and it'll do what you want, whilst leaving it enabled for users by default. Dave From ivazquez at ivazquez.net Wed Feb 1 00:40:17 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 31 Jan 2006 19:40:17 -0500 Subject: Make hardlinking kernel-devel optional In-Reply-To: <20060201002534.GO16557@redhat.com> References: <20060131194417.6d7e411e@dhcp05.addix.net> <20060131222114.GD29937@redhat.com> <1138752353.24298.6.camel@ignacio.lan> <20060201002534.GO16557@redhat.com> Message-ID: <1138754417.24298.9.camel@ignacio.lan> On Tue, 2006-01-31 at 19:25 -0500, Dave Jones wrote: > Removing the Prereq: /usr/sbin/hardlink from the spec (which I just did in CVS) > should have the effect that you can now rpm -e hardlink, and it'll > do what you want, whilst leaving it enabled for users by default. And making it so that either 1) you don't have hardlink, or 2) forcing you to uninstall it, install kernel-devel, and then reinstall it. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cmadams at hiwaay.net Wed Feb 1 01:26:03 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 31 Jan 2006 19:26:03 -0600 Subject: Make hardlinking kernel-devel optional In-Reply-To: <20060131222114.GD29937@redhat.com> References: <20060131194417.6d7e411e@dhcp05.addix.net> <20060131222114.GD29937@redhat.com> Message-ID: <20060201012603.GC1210517@hiwaay.net> Once upon a time, Dave Jones said: > only if you have a huge number of kernels installed, which shouldn't be the case. If you don't have a huge number of kernels installed, hardlink isn't a big benefit. The kernel-devel package is 14MB installed. Hardlinking with 3 kernel-devel packages installed will save no more than 28MB (and probably less). That is lost in the noise of a normal system. Just doing "yum update" will often use much more than 28MB; even after a "yum clean packages" on a rawhide system I see 90MB in /var/cache/yum. Also, hardlink apparently may not be very efficient. I whipped up a version in perl that (in my limited testing) appears faster. Others have written C and C++ (and maybe IIRC python) versions that also appear to be faster. How about replacing it with something better performing? The solution of "rpm -e hardlink" is also not very good, as some people use hardlink for other things (and so can't just remove it). As a compromise, how about only kicking hardlink off if there are more than X kernel-devel packages installed (where X is more than the norm, like 5)? Or how about making the hardlink run as a cron job? Another though: why the "find | while ; do hardlink"? You should just be able to do: if [ -x /usr/sbin/hardlink ] ; then /usr/sbin/hardlink /usr/src/kernels/*FC* fi The post script is forking hardlink over 5000 times as well as causing thousands of repeated directory lookups by find and the shell (that hardlink then has to do anyway), instead of just letting one run of hardlink do its job (it should recurse just fine). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From davej at redhat.com Wed Feb 1 01:48:31 2006 From: davej at redhat.com (Dave Jones) Date: Tue, 31 Jan 2006 20:48:31 -0500 Subject: Make hardlinking kernel-devel optional In-Reply-To: <20060201012603.GC1210517@hiwaay.net> References: <20060131194417.6d7e411e@dhcp05.addix.net> <20060131222114.GD29937@redhat.com> <20060201012603.GC1210517@hiwaay.net> Message-ID: <20060201014831.GS16557@redhat.com> On Tue, Jan 31, 2006 at 07:26:03PM -0600, Chris Adams wrote: > If you don't have a huge number of kernels installed, hardlink isn't a > big benefit. The kernel-devel package is 14MB installed. Hardlinking > with 3 kernel-devel packages installed will save no more than 28MB (and > probably less). That is lost in the noise of a normal system. Just > doing "yum update" will often use much more than 28MB; even after a "yum > clean packages" on a rawhide system I see 90MB in /var/cache/yum. "We can spew 28MB in app X because app Y spews 90MB" doesn't make a great deal of sense. The cumulative effects if every package took the same attitude would be a vastly bloated minimal install. > Also, hardlink apparently may not be very efficient. I whipped up a > version in perl that (in my limited testing) appears faster. Others > have written C and C++ (and maybe IIRC python) versions that also appear > to be faster. How about replacing it with something better performing? File a bug against it with patches, and I'm sure jnovy at redhat will be interested. > The solution of "rpm -e hardlink" is also not very good, as some people > use hardlink for other things (and so can't just remove it). true > As a compromise, how about only kicking hardlink off if there are more > than X kernel-devel packages installed (where X is more than the norm, > like 5)? Or how about making the hardlink run as a cron job? I'll merge Ignacio's change to source /etc/sysconfig/kernel, in addition to the other change, > Another though: why the "find | while ; do hardlink"? You should just > be able to do: > > if [ -x /usr/sbin/hardlink ] ; then > /usr/sbin/hardlink /usr/src/kernels/*FC* > fi > > The post script is forking hardlink over 5000 times as well as causing > thousands of repeated directory lookups by find and the shell (that > hardlink then has to do anyway), instead of just letting one run of > hardlink do its job (it should recurse just fine). I've often wondered why it was written that way too. Arjan, do you recall ? Dave From seandarcy2 at gmail.com Wed Feb 1 02:10:53 2006 From: seandarcy2 at gmail.com (sean) Date: Tue, 31 Jan 2006 21:10:53 -0500 Subject: open office fails to start this week Message-ID: on amd64, open office refuses to start. The Open Office blue splash box comes up, then it dies. Same result from oowriter ooimpress oocalc, and /usr/lib/openoffice.org2.0/program/soffice. openoffice.org-core-2.0.1.1-8.2 openoffice.org-writer-2.0.1.1-8.2 openoffice.org-calc-2.0.1.1-8.2 openoffice.org-impress-2.0.1.1-8.2 It worked last week! Anybody else seeing this? sean From pemboa at gmail.com Wed Feb 1 02:42:07 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 31 Jan 2006 20:42:07 -0600 Subject: Questionable g++ behaviour Message-ID: <16de708d0601311842t3a40bd11r347717891ed33285@mail.gmail.com> I am by no means a guru in C++, so I come to the list to ask advice. I have been informed that C++ does not allow for array declarations using varaibles as the size parameter: [] Yet g++ clearly allows this. Is this my misunderstanding? If so, can anyone point me in the direction of the appropriate C++ specs so that I may use as evidence? Or is this a bug or gotcha in g++? If so, should I file a bug report? I have attached a sample .cpp which compiles and runs for me. Thank you. -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: questionable.cpp Type: text/x-c++src Size: 281 bytes Desc: not available URL: From katzj at redhat.com Wed Feb 1 02:55:47 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 31 Jan 2006 21:55:47 -0500 Subject: Make hardlinking kernel-devel optional In-Reply-To: <20060201014831.GS16557@redhat.com> References: <20060131194417.6d7e411e@dhcp05.addix.net> <20060131222114.GD29937@redhat.com> <20060201012603.GC1210517@hiwaay.net> <20060201014831.GS16557@redhat.com> Message-ID: <1138762547.7447.30.camel@bree.local.net> On Tue, 2006-01-31 at 20:48 -0500, Dave Jones wrote: > On Tue, Jan 31, 2006 at 07:26:03PM -0600, Chris Adams wrote: > > The post script is forking hardlink over 5000 times as well as causing > > thousands of repeated directory lookups by find and the shell (that > > hardlink then has to do anyway), instead of just letting one run of > > hardlink do its job (it should recurse just fine). > > I've often wondered why it was written that way too. > Arjan, do you recall ? It does it so that you ensure that you're only hardlinking the same copy of any foo.h in the directory layout instead of all copies Jeremy From stickster at gmail.com Wed Feb 1 02:56:24 2006 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 31 Jan 2006 21:56:24 -0500 Subject: Dovecot configuration format change [was Re: rawhide report: 20060131 changes] In-Reply-To: <1138704267.3678.25.camel@localhost.localdomain> References: <200601310846.k0V8kq9D027656@porkchop.devel.redhat.com> <1138704267.3678.25.camel@localhost.localdomain> Message-ID: <1138762584.25784.1.camel@localhost.localdomain> On Tue, 2006-01-31 at 10:44 +0000, Mark McLoughlin wrote: > On Tue, 2006-01-31 at 03:46 -0500, Build System wrote: > > > > dovecot-1.0-0.beta2.1 > > --------------------- > > * Mon Jan 30 2006 Petr Rockai - 1.0-0.beta2.1 > > - fix spec to work with BUILD_DIR != SOURCE_DIR > > - forward-port and split pam-nocred patch > > > > * Mon Jan 23 2006 Petr Rockai - 1.0-0.beta2 > > - new upstream version, hopefully fixes #173928, #163550 > > - fix #168866, use install -p to install documentation > > Heads up to people - the configuration file format has changed since > 0.99.14. See: > > http://wiki.dovecot.org/UpgradingDovecot This has made it to the release notes as well: http://fedoraproject.org/wiki/Docs/Beats/PackageNotes -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tromey at redhat.com Wed Feb 1 02:53:06 2006 From: tromey at redhat.com (Tom Tromey) Date: 31 Jan 2006 19:53:06 -0700 Subject: Questionable g++ behaviour In-Reply-To: <16de708d0601311842t3a40bd11r347717891ed33285@mail.gmail.com> References: <16de708d0601311842t3a40bd11r347717891ed33285@mail.gmail.com> Message-ID: >>>>> "Arthur" == Arthur Pemberton writes: Arthur> I have been informed that C++ does not allow for array Arthur> declarations using varaibles as the size parameter: Arthur> Yet g++ clearly allows this. Is this my misunderstanding? It is a g++ extension. See the node 'Variable Length' in the gcc manual. Tom From katzj at redhat.com Wed Feb 1 03:03:53 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 31 Jan 2006 22:03:53 -0500 Subject: Rescue CD (and other) questions In-Reply-To: <43DFDE77.3000907@cornell.edu> References: <43DFDE77.3000907@cornell.edu> Message-ID: <1138763033.7447.34.camel@bree.local.net> On Tue, 2006-01-31 at 17:02 -0500, Ivan Gyurdiev wrote: > 1) Why isn't /selinux automatically mounted for existing installations? > Without it, rpm installs do not work when rescuing from a > selinux-enabled kernel, such as the one in FC5T2 (because attempts to > set the file context fail). Because no one has filed a bug asking for it. > 2) I want to migrate data from an old disk onto a new one. Currently I > have two logical volumes that span both disks, and take up 100% of the > space. I'd like to reduce a lv, in order to migrate the data. Doesn't > seem to work from the rescue CD. > > lvresize -r -L -120G /dev/cobra/home2 says: > fsadm: execlp failed: No such file or directory. > > Any suggestions? One of the things it's looking at is > /proc/lvm/VGs/cobra.. (/proc/lvm doesn't exist). That looks like old lvm1 tools -- are you sure you're using a current rescue CD? > 3) Unrelated question: When I originally added my sata drive to the > volume group, my kernel would no longer boot. Investigation showed that > sd_mod doesn't get loaded into the initrd, and without it nothing works. > I had to edit mkinitrd to make it put that module in the archive. Why > would that happen? You need to make sure that there's an appropriate scsi_hostadapter line in /etc/modprobe.conf for the module for your SATA chipset. That will then key mkinitrd to include sd_mod Jeremy From ndbecker2 at gmail.com Wed Feb 1 03:16:43 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 31 Jan 2006 22:16:43 -0500 Subject: open office fails to start this week References: Message-ID: sean wrote: > on amd64, open office refuses to start. The Open Office blue > splash box comes up, then it dies. Same result from > oowriter ooimpress oocalc, and > /usr/lib/openoffice.org2.0/program/soffice. > > openoffice.org-core-2.0.1.1-8.2 > openoffice.org-writer-2.0.1.1-8.2 > openoffice.org-calc-2.0.1.1-8.2 > openoffice.org-impress-2.0.1.1-8.2 > > It worked last week! > > Anybody else seeing this? > > sean > Lot of problems with new kernels on x86_64 with threads. Try an older kernel. From pemboa at gmail.com Wed Feb 1 03:19:37 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 31 Jan 2006 21:19:37 -0600 Subject: Questionable g++ behaviour In-Reply-To: References: <16de708d0601311842t3a40bd11r347717891ed33285@mail.gmail.com> Message-ID: <16de708d0601311919o69dcc9aalf9e25c12b59cc51@mail.gmail.com> On 31 Jan 2006 19:53:06 -0700, Tom Tromey wrote: > > >>>>> "Arthur" == Arthur Pemberton writes: > > Arthur> I have been informed that C++ does not allow for array > Arthur> declarations using varaibles as the size parameter: > > Arthur> Yet g++ clearly allows this. Is this my misunderstanding? > > It is a g++ extension. See the node 'Variable Length' in the gcc > manual. > > Tom Thank you. I looked through `man gcc` and didn't find it. But was able to google it to: http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wrrhdev at riede.org Wed Feb 1 03:22:14 2006 From: wrrhdev at riede.org (Willem Riede) Date: Tue, 31 Jan 2006 22:22:14 -0500 Subject: open office fails to start this week In-Reply-To: (from seandarcy2@gmail.com on Tue Jan 31 21:10:53 2006) References: Message-ID: <1138764134l.26638l.0l@athena.riede.org> On 01/31/2006 09:10:53 PM, sean wrote: > on amd64, open office refuses to start. The Open Office blue > splash box comes up, then it dies. Same result from > oowriter ooimpress oocalc, and > /usr/lib/openoffice.org2.0/program/soffice. > > openoffice.org-core-2.0.1.1-8.2 > openoffice.org-writer-2.0.1.1-8.2 > openoffice.org-calc-2.0.1.1-8.2 > openoffice.org-impress-2.0.1.1-8.2 > > It worked last week! > > Anybody else seeing this? Yes! https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179519 Willem Riede. From cmadams at hiwaay.net Wed Feb 1 04:12:29 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 31 Jan 2006 22:12:29 -0600 Subject: Make hardlinking kernel-devel optional In-Reply-To: <1138762547.7447.30.camel@bree.local.net> References: <20060131194417.6d7e411e@dhcp05.addix.net> <20060131222114.GD29937@redhat.com> <20060201012603.GC1210517@hiwaay.net> <20060201014831.GS16557@redhat.com> <1138762547.7447.30.camel@bree.local.net> Message-ID: <20060201041229.GD1210517@hiwaay.net> Once upon a time, Jeremy Katz said: > It does it so that you ensure that you're only hardlinking the same copy > of any foo.h in the directory layout instead of all copies Why? hardlink isn't going to replace files that are different, so there is no gain in not letting hardlink link all copies that are the same. It is smart enough to look at the stat() info before reading the contents for comparison, so files of different sizes aren't going to be compared just because they have the same name. The whole point of running hardlink is to reduce disk usage; why not let it try to do the best job possible? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From louisg00 at bellsouth.net Wed Feb 1 04:47:38 2006 From: louisg00 at bellsouth.net (louisg00 at bellsouth.net) Date: Tue, 31 Jan 2006 23:47:38 -0500 Subject: Gnome weather applet crashes on startup Message-ID: <20060201044738.NUEC29035.ibm71aec.bellsouth.net@mail.bellsouth.net> This is on rawhide latest. From tla-ml at rasmil.dk Wed Feb 1 13:32:06 2006 From: tla-ml at rasmil.dk (Tim Lauridsen) Date: Wed, 01 Feb 2006 08:32:06 -0500 Subject: libnotify don't work for root. In-Reply-To: <1138722898.12122.72.camel@remedyz.boston.redhat.com> References: <43DF9A36.2000908@rasmil.dk> <1138722898.12122.72.camel@remedyz.boston.redhat.com> Message-ID: <43E0B856.9080602@rasmil.dk> John (J5) Palmieri wrote: > On Tue, 2006-01-31 at 12:11 -0500, Tim Lauridsen wrote: > >> Hi. >> >> I have tried to make libnotify / notification-daemon work from python. >> >> I have made this sample, it is works ok, when running as a normal user, >> but it dont work when running as root. >> >> http://linux.rasmil.dk/dnl/test/test-dbus.py >> >> It is the same when i am using the >> notify-send "foo" "bar" >> it works as normal user, but not as root. >> >> Anybody have any clues ??? >> > > When you say it doesn't work for root do you mean you are logged in as > the user and you try to send from root? That is exactly, what i am trying to do, i want to send notifications to the user from yumex (which is running as root). > In that case it is expected not > to work. Every user has a session bus which is what libnotify uses. > Only applications running in that session can access that bus. If you > want root to send notifications you will have to relay the message > through a proxy which listens on the system bus and then sends the > message over the users session bus. Nothing like that has been built > yet. > > Ok, i see, thanks for make it clear for me. Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From maschino at jouy.inra.fr Wed Feb 1 08:22:39 2006 From: maschino at jouy.inra.fr (Emeric Maschino) Date: Wed, 01 Feb 2006 09:22:39 +0100 Subject: Gnome weather applet crashes on startup In-Reply-To: <20060201044738.NUEC29035.ibm71aec.bellsouth.net@mail.bellsouth.net> References: <20060201044738.NUEC29035.ibm71aec.bellsouth.net@mail.bellsouth.net> Message-ID: <1138782159.5061.1.camel@localhost.localdomain> Hi, Le mardi 31 janvier 2006 ? 23:47 -0500, louisg00 at bellsouth.net a ?crit : > This is on rawhide latest. As well as gnome-power-manager on my Itanium workstation. However, gnome-power-manager can be started in CLI. Cheers, ?meric From buildsys at redhat.com Wed Feb 1 08:39:38 2006 From: buildsys at redhat.com (Build System) Date: Wed, 1 Feb 2006 03:39:38 -0500 Subject: rawhide report: 20060201 changes Message-ID: <200602010839.k118dcOp016672@porkchop.devel.redhat.com> Updated Packages: NetworkManager-0.5.1-8.cvs20060131 ---------------------------------- * Tue Jan 31 2006 Dan Williams 0.5.1-8.cvs20060131 - Switch to autostarting the applet instead of having it be session-managed - Work better with non-broadcasting access points - Add more manufacturer default SSIDs to the blacklist * Tue Jan 31 2006 Dan Williams 0.5.1-7.cvs20060131 - Longer association timeout - Fix some SELinux issues - General bug and cosmetic fixes anaconda-10.91.11-1 ------------------- * Tue Jan 31 2006 Paul Nasrat - 10.91.11-1 - Factor some yum stuff into yum - Text Clarification (#178105) - Don't use install only pkgs (#179381) - Various dmraid and bootloader fixes (pjones) * Tue Jan 31 2006 Peter Jones - 10.91.10-1 - add dmraid device renaming support for kickstart (pjones) - fix paths for expat (clumens) - remove unused functions (clumens) apr-util-1.2.2-4 ---------------- * Mon Jan 30 2006 Joe Orton 1.2.2-4 - rebuild to drop reference to libexpat.la at-spi-1.7.4-1 -------------- * Tue Jan 31 2006 Matthias Clasen 1.7.4-1 - Update to 1.7.4 beagle-0.2.1-1 -------------- * Tue Jan 31 2006 Christopher Aillon 0.2.1-1 - Update to beagle 0.2.1 - Use sqlite3 instead of sqlite2 * Tue Jan 31 2006 Ray Strode 0.2.0-4 - don't blindly run beagled in current working directory (bug 177675) * Tue Jan 24 2006 Than Ngo 0.2.0-3 - added --add-only-show-in=gnome to the desktop-file-install calls booty-0.65-1 ------------ * Tue Jan 31 2006 Peter Jones - 0.65-1 - add support for reprobing device bootloaderInfo.drivelist cadaver-0.22.3-2 ---------------- * Tue Jan 31 2006 Joe Orton 0.22.3-2 - rebuild for neon 0.25.x cairo-1.0.2-4 ------------- * Tue Jan 31 2006 Ray Strode 1.0.2-4 - add patch from Tim Mayberry to support embbedded bitmap fonts (bug 176910) * Tue Jan 03 2006 Jesse Keating 1.0.2-3.2 - rebuilt again * Fri Dec 09 2005 Jesse Keating - rebuilt dovecot-1.0-0.beta2.2 --------------------- * Tue Jan 31 2006 Petr Rockai - 1.0-0.beta2.2 - update URL in description - call dovecot --build-ssl-parameters in postinst as per #179430 doxygen-1:1.4.6-1 ----------------- * Tue Jan 31 2006 Than Ngo 1.4.6-1 - 1.4.6 evolution-connector-2.5.9.0-2 ----------------------------- * Tue Jan 31 2006 Ray Strode - 2.5.9.0-2 - add builddeps (bug 137879) evolution-data-server-1.5.90-2 ------------------------------ * Tue Jan 31 2006 Ray Strode - 1.5.90-2 - add build deps (bug 137553) evolution-sharp-0.10.2-7 ------------------------ * Tue Jan 31 2006 Christopher Aillon 0.10.2-7 - Update evolution-sharp-evo26.patch look for a SO_NUM of 7 for edataserver - BuildRequire evolution-devel * Tue Jan 31 2006 Christopher Aillon 0.10.2-6 - Rebuild expat-1.95.8-8 -------------- * Tue Jan 31 2006 Joe Orton 1.95.8-8 - restore .la file for apr-util f-spot-0.1.8-1 -------------- * Tue Jan 31 2006 Christopher Aillon - 0.1.8-1 - Update to 0.1.8 - Use sqlite3 instead of sqlite2 * Tue Jan 31 2006 Ray Strode - 0.1.5-3 - don't blindly run f-spot from current working directory (bug 177407) festival-1.95-5 --------------- * Sun Jan 22 2006 Ray Strode - 1.95-5 - get gnopernicus working again. Patch from Fernando Herrera (bug 178312) - add a lot of compiler flags and random cruft to get festival to build with gcc 4.1 * Fri Dec 09 2005 Jesse Keating - rebuilt fontconfig-2.3.93.cvs20060131-1 ------------------------------- * Tue Jan 31 2006 Matthias Clasen - 2.3.93.cvs20060131-1 - Newer cvs snapshot gcc-4.1.0-0.18 -------------- * Tue Jan 31 2006 Jakub Jelinek 4.1.0-0.18 - update from gcc-4_1-branch (-r110317:110433) - PRs c++/25855, c++/25999, fortran/17911, fortran/18578, fortran/18579, fortran/20857, fortran/20885, fortran/20895, fortran/25030, fortran/25835, fortran/25951, java/21428, libgfortran/25835, target/14798, target/25706, target/25718, target/25947, target/26018, testsuite/25318 - add -mtune=generic support for i?86 and x86_64 (Jan Hubicka, H.J. Lu, Evandro Menezes) - use -mtune=generic by default if neither -march= nor -mtune= is specified on command line on i?86 or x86_64 - updated s390{,x} long double patch, fixing ICEs on s390x glibc build (Andreas Krebbel, Ulrich Weigand) gdm-1:2.13.0.7-1 ---------------- * Tue Jan 31 2006 Ray Strode - 1:2.13.0.7-1 - update to 2.13.0.7 * Mon Jan 30 2006 Bill Nottingham - silence gdm-safe-restart gecko-sharp2-0.11-4 ------------------- * Tue Jan 31 2006 Christopher Aillon 0.11-4 - Rebuild gmime-2.1.19-2 -------------- * Tue Jan 31 2006 Christopher Aillon - 2.1.19-2 - Rebuild gnome-applets-1:2.13.3-3 ------------------------ * Tue Jan 31 2006 Matthias Clasen 2.13.3-3 - Update gstreamer requires gnome-power-manager-2.13.5-2 ---------------------------- * Tue Jan 31 2006 Matthias Clasen - 2.13.5-2 - rebuild * Thu Jan 26 2006 Ray Strode - 2.13.5-1 - packaging tweaks * Thu Jan 26 2006 Christopher Aillon 2.13.5-1 - Update to 2.13.5 gnome-screensaver-2.13.90-2 --------------------------- * Tue Jan 31 2006 Ray Strode - 2.13.90-2 - try to migrate xscreensaver screensavers (bug 172715) gnome-system-monitor-2.13.90-1 ------------------------------ * Tue Jan 31 2006 Matthias Clasen 2.13.90-1 - Update to 2.13.90 gsf-sharp-0.6-6 --------------- * Tue Jan 31 2006 Christopher Aillon 0.6-6 - Rebuild gtk-sharp2-2.8.0-1 ------------------ * Tue Jan 31 2006 Christopher Aillon 2.8.0-1 - Update to 2.8.0 gtkhtml3-3.9.90-3 ----------------- * Tue Jan 31 2006 Matthias Clasen - 3.9.90-3 - Actually apply the patch * Tue Jan 31 2006 Matthias Clasen - 3.9.90-2 - Fix a crash imake-1.0.1-1 ------------- * Wed Jan 18 2006 Mike A. Harris 1.0.1-1 - Updated all packages to version 1.0.1 from X11R7.0 initscripts-8.23-1 ------------------ * Tue Jan 31 2006 Peter Jones 8.23-1 - rc.sysinit: do a better job of not activating already active dmraids * Tue Jan 31 2006 Bill Nottingham 8.22-1 - remove references to /usr/X11R6/bin (#177938) - rc.sysinit: fix SELinux message formatting (#178532) - rc.sysinit: clean cvs as well (#178539, ) - init.d/halt: move halt.local so that it runs before / is remounted r/o (#179314) - rc.sysinit: don't activate already active dmraids () - rc.sysinit: don't mount usbfs, libusb no longer uses it - init.d/functions: Add -p to status() (#134363, ) - init.d/functions: Separate /var/run/*.pid handling and pidof calls to private functions (#63440, ) - init.d/functions: update for current LSB, including -p pidfile (#99325, #134363, , ) - getkey: various cleanups, add man page (#54481, ) - lang.sh: don't always call consoletype () libXext-1.0.0-3 --------------- * Tue Jan 31 2006 Mike A. Harris 1.0.0-3 - Added "Requires: xorg-x11-proto-devel >= 7.0-1" to devel package (#173713) - Added "libX11-devel" to devel package (#176078) libXvMC-1.0.1-2 --------------- * Tue Jan 31 2006 Mike A. Harris 1.0.1-2 - Added "Requires: libXv-devel, xorg-x11-proto-devel" to fix (#176862) libc-client-2004g-2 ------------------- * Tue Jan 31 2006 Joe Orton 2004g-2 - bump soname (#179017) libgdiplus-1.1.13.2-1 --------------------- * Tue Jan 31 2006 Christopher Aillon - 1.1.13.2-1 - Update to 1.1.13.2 mkinitrd-5.0.18-1 ----------------- * Tue Jan 31 2006 Peter Jones - 5.0.18-1 - make mkinitrd discover dm uuids - add uuid support to nash's "dm create" and "dm partadd" - add nash command "dm get_uuid $NAME" - add support for renamed dm raids mono-1.1.13.2-1 --------------- * Tue Jan 31 2006 Christopher Aillon - 1.1.13.2-1 - Update to 1.1.13.2 ncurses-5.5-18 -------------- * Tue Jan 31 2006 Jindrich Novy 5.5-18 - add --with-chtype=long to avoid type clashes on x86_64 (#178824) - spec cleanup neon-0.25.5-1 ------------- * Tue Jan 31 2006 Joe Orton 0.25.5-1 - update to 0.25.5 openldap-2.3.19-2 ----------------- * Tue Jan 10 2006 Jay Fenlason 2.3.19-2 - Upgrade to 2.3.19, which upstream now considers stable - Modify the -config.patch, ldap.init, and this spec file to put the pid file and args file in an ldap-owned openldap subdirectory under /var/run. - Move back_sql* out of /usr/sbin/openldap , which requires hand-moving slapd and slurpd to _sbindir, and recreating symlinks by hand. - Retire openldap-2.3.11-ads.patch, which went upstream. - Update the ldap.init script to run slaptest as the ldap user rather than as root. This solves bz#150172 Startup failure after database problem - Add to the servers post and preun scriptlets so that on preun, the database is slapcatted to /var/lib/ldap/upgrade.ldif and the database files are saved to /var/lib/ldap/rpmorig. On post, if /var/lib/ldap/upgrade.ldif exists, it is slapadded. This means that on upgrades from 2.3.16-2 to higher versions, the database files may be automatically upgraded. Unfortunatly, because of the changes to the preun scriptlet, users have to do the slapcat, etc by hand when upgrading to 2.3.16-2. Also note that the /var/lib/ldap/rpmorig files need to be removed by hand because automatically removing your emergency fallback files is a bad idea. - Upgrade internal bdb to db-4.4.20. For a clean upgrade, this will require that users slapcat their databases into a temp file, move /var/lib/ldap someplace safe, upgrade the openldap rpms, then slapadd the temp file. passwd-0.71-3 ------------- * Tue Jan 31 2006 Steve Grubb 0.71-3 - Adjust audit patch so it builds without libaudit php-5.1.2-4 ----------- * Tue Jan 31 2006 Joe Orton 5.1.2-4 - rebuild for new libc-client soname pykickstart-0.16-1 ------------------ * Tue Jan 31 2006 Chris Lumens 0.16-1 - Give dmraid string an initial value. - Handle None on partition size. * Tue Jan 31 2006 Peter Jones 0.15-1 - Add dmraid support python-pyblock-0.12-1 --------------------- * Tue Jan 31 2006 Peter Jones - 0.12-1 - split __init__.py into separate files according to function - disable "nosync" hack for now - fix a refcounting bug in pydmraid_raidset_get_dm_table() - add block.RaidDev.__cmp__() - fix some type errors gcc can't check for when using pyblock_potoll - be a little pickier about types for mode, devices, and sizes. - add make rules for debugging - fix "_init__" typo - always use local import paths, and be much more strict about namespaces - always make a new dm.device in BlockDev.From*() - better defaults in BlockDev.create() - add setter for block.dmraid.raidset.name, and rework RaidSet.set_name() - rework RaidDev.get_bdev() - rework "prefix" for RaidSet and RaidDev - add getter for block.dmraid.raidset.map - change arg order on block.dm.map.__init__() since there's no way to pass keyword args through the "abstract" interface. - use self.name not self.rs.name in the RaidSet, and make changing the name work. - make pydm_map_compare() compare names _last_, so we can compare a map that's been renamed with its earlier instantiations correctly. - mark a device as degraded if there's any descrepancy at all between the number of members we find vs what we expect rpm-4.4.2-15 ------------ * Mon Jan 30 2006 Paul Nasrat - 4.4.2-15 - Rebuild for newer neon - Fix scriptlet deadlock (#146549) * Wed Jan 18 2006 Paul Nasrat - 4.4.2-14 - Don't emit perl(main) (#177960) setools-2.3-1 ------------- * Tue Jan 31 2006 Dan Walsh 2.3-1 - Update from upstream * apol: added new MLS components tab for sensitivities, levels, and categories. Changed users tab to support ranges and default levels. added range transition tab for searching range Transition rules. added new tab for network context components. added new tab for file system context components. * libapol: added binpol support for MLS, network contexts, and file system contexts. * seinfo: added command line options for MLS components. added command line options for network contexts and file system contexts. * sesearch: added command line option for searching for rules by conditional boolean name. * seaudit: added new column in the log view for the 'comm' field found in auditd log files. added filters for the 'comm' field and 'message' field. * manpages: added manpages for all tools. setup-2.5.48-1 -------------- * Tue Jan 31 2006 Phil Knirsch 2.4.48-1 - Switched to the new large /etc/services file which fixes #112298, #133683, - Fixed pathmunge problem with bashrc (#123621) - Removed /usr/X11R6/bin from default PATH (#173856) * Tue Jan 24 2006 Phil Knirsch - Fixed bug with PROMPT_COMMAND being broken for wierd dirs (#142125) - Added hfsplus to know filesystems (#172820) * Mon Oct 17 2005 Bill Nottingham - make motd noreplace (#170539) sqlite-3.3.3-1 -------------- * Tue Jan 31 2006 Christopher Aillon - 3.3.3-1 - Update to 3.3.3 * Tue Jan 31 2006 Christopher Aillon - 3.3.2-1 - Update to 3.3.2 * Tue Jan 24 2006 Paul Nasrat - 3.2.8-1 - Add --enable-threadsafe (Nicholas Miell) - Update to 3.2.8 subversion-1.3.0-4 ------------------ * Tue Jan 31 2006 Joe Orton 1.3.0-4 - run check-swig-py in %check (#178448) - relax JDK requirement (Kenneth Porter, #177367) * Tue Jan 31 2006 Joe Orton 1.3.0-3 - rebuild for neon 0.25 tomboy-0.3.4-2 -------------- * Tue Jan 31 2006 Christopher Aillon - 0.3.4-2 - Rebuild usermode-1.85-2 --------------- * Tue Jan 31 2006 Jindrich Novy 1.85-2 - add gettext, libattr-devel, libSM-devel dependencies vnc-4.1.1-34 ------------ * Tue Jan 31 2006 Tim Waugh 4.1.1-34 - Updated xorg-x11-server to 1.0.1-1. xen-3.0-0.20060130.fc5.2 ------------------------ * Tue Jan 31 2006 Bill Nottinghham 3.0-0.20060130.fc5.2 - use the default network device, don't hardcode eth0 * Tue Jan 31 2006 - 3.0-0.20060130.fc5.1 - Add xenguest-install.py in /usr/sbin xorg-x11-apps-1.0.1-1 --------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.1-1 - Upgraded all apps to version 1.0.1 from X11R7.0 xorg-x11-resutils-1.0.1-1 ------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.1-1 - Update all resource utils to version 1.0.1 from X11R7.0 xorg-x11-server-utils-1.0.1-1 ----------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.1-1 - Updated all packages to the versions from X11R7.0 xorg-x11-twm-1:1.0.1-1 ---------------------- * Wed Jan 18 2006 Mike A. Harris 1:1.0.1-1 - Updated to twm 1.0.1 from X11R7.0 xorg-x11-utils-1.0.1-1 ---------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.1-1 - Updated all tarballs to versions from X11R7.0 xorg-x11-xauth-1:1.0.1-1 ------------------------ * Wed Jan 18 2006 Mike A. Harris 1:1.0.1-1 - Updated to xauth 1.0.1 from X11R7.0 xorg-x11-xbitmaps-1.0.1-1 ------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.1-1 - Updated to xbitmaps 1.0.1 from X11R7.0 xorg-x11-xfs-1:1.0.1-1 ---------------------- * Mon Jan 16 2006 Mike A. Harris 1:1.0.1-1 - Updated all tarballs to version 1.0.1 from X11R7.0 xorg-x11-xfwp-1.0.1-1 --------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.1-1 - Updated all tarballs to version 1.0.1 from X11R7.0 xorg-x11-xinit-1.0.1-1 ---------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.1-1 - Updated to xinit 1.0.1 from X11R7.0 xorg-x11-xkb-utils-1.0.1-1 -------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.1-1 - Updated all apps to version 1.0.1 from X11R7.0 xorg-x11-xkbdata-1.0.1-1 ------------------------ * Wed Jan 18 2006 Mike A. Harris 1.0.1-1 - Updated to xbitmaps 1.0.1 from X11R7.0 xorg-x11-xsm-1.0.1-1 -------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.1-1 - Updated all apps to version 1.0.1 from X11R7.0 yum-2.5.1-3 ----------- * Tue Jan 31 2006 Paul Nasrat - 2.5.1-3 - Merge upstream patches (sortabletransactiondata, grouplists) Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 openoffice.org-core - 1:2.0.1.1-8.2.i386 requires libneon.so.24 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- ccs-devel - 1.0.2-3.1.ppc requires ccs = 0:1.0.2-3.1 gulm - 1.0.4-2.FC5.1.ppc requires ccs openoffice.org-core - 1:2.0.1.1-8.2.ppc requires libneon.so.24 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.3-2.s390 requires kernel >= 0:2.6.9-11 systemtap - 0.5.3-2.s390 requires kernel-devel Broken deps for s390x ---------------------------------------------------------- libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) systemtap - 0.5.3-2.s390x requires kernel >= 0:2.6.9-11 systemtap - 0.5.3-2.s390x requires kernel-devel Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 openoffice.org-core - 1:2.0.1.1-8.2.i386 requires libneon.so.24 From mlists at juma.me.uk Wed Feb 1 09:54:12 2006 From: mlists at juma.me.uk (Ismael Juma) Date: Wed, 01 Feb 2006 09:54:12 +0000 Subject: Gnome weather applet crashes on startup In-Reply-To: <20060201044738.NUEC29035.ibm71aec.bellsouth.net@mail.bellsouth.net> References: <20060201044738.NUEC29035.ibm71aec.bellsouth.net@mail.bellsouth.net> Message-ID: <1138787652.6039.2.camel@localhost.localdomain> On Tue, 2006-01-31 at 23:47 -0500, louisg00 at bellsouth.net wrote: > This is on rawhide latest. I think this is the bug: http://bugzilla.gnome.org/show_bug.cgi?id=327406 . Regards, Ismael From bart.vanbrabant at zoeloelip.be Wed Feb 1 11:17:08 2006 From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant) Date: Wed, 01 Feb 2006 12:17:08 +0100 Subject: rawhide report: 20060201 changes In-Reply-To: <200602010839.k118dcOp016672@porkchop.devel.redhat.com> References: <200602010839.k118dcOp016672@porkchop.devel.redhat.com> Message-ID: <43E098B4.8000604@zoeloelip.be> > sqlite-3.3.3-1 > -------------- > * Tue Jan 31 2006 Christopher Aillon - 3.3.3-1 > - Update to 3.3.3 > > * Tue Jan 31 2006 Christopher Aillon - 3.3.2-1 > - Update to 3.3.2 > > * Tue Jan 24 2006 Paul Nasrat - 3.2.8-1 > - Add --enable-threadsafe (Nicholas Miell) > - Update to 3.2.8 > > This update killed my yum. I tried removing all the metadata and reinstalling yum but it didn't help. When it starts importing the metadata files yum keeps allocating memory and does nothing. I don't know if other have this problem but be careful. I ran f-spot and beagle after so I can't revert sqlite because of the database upgrade. Bart -- Bart Vanbrabant PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From sundaram at fedoraproject.org Wed Feb 1 11:22:39 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 01 Feb 2006 16:52:39 +0530 Subject: rawhide report: 20060201 changes In-Reply-To: <43E098B4.8000604@zoeloelip.be> References: <200602010839.k118dcOp016672@porkchop.devel.redhat.com> <43E098B4.8000604@zoeloelip.be> Message-ID: <43E099FF.2060402@fedoraproject.org> Bart Vanbrabant wrote: >>sqlite-3.3.3-1 >>-------------- >>* Tue Jan 31 2006 Christopher Aillon - 3.3.3-1 >>- Update to 3.3.3 >> >>* Tue Jan 31 2006 Christopher Aillon - 3.3.2-1 >>- Update to 3.3.2 >> >>* Tue Jan 24 2006 Paul Nasrat - 3.2.8-1 >>- Add --enable-threadsafe (Nicholas Miell) >>- Update to 3.2.8 >> >> >> >> >This update killed my yum. I tried removing all the metadata and >reinstalling yum but it didn't help. When it starts importing the >metadata files yum keeps allocating memory and does nothing. >I don't know if other have this problem but be careful. I ran f-spot and >beagle after so I can't revert sqlite because of the database upgrade. > >Bart > > > Check this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179547 -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From bart.vanbrabant at zoeloelip.be Wed Feb 1 11:25:30 2006 From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant) Date: Wed, 01 Feb 2006 12:25:30 +0100 Subject: rawhide report: 20060201 changes In-Reply-To: <43E099FF.2060402@fedoraproject.org> References: <200602010839.k118dcOp016672@porkchop.devel.redhat.com> <43E098B4.8000604@zoeloelip.be> <43E099FF.2060402@fedoraproject.org> Message-ID: <43E09AAA.2000708@zoeloelip.be> Rahul Sundaram wrote: > Bart Vanbrabant wrote: > >>> sqlite-3.3.3-1 >>> -------------- >>> * Tue Jan 31 2006 Christopher Aillon - 3.3.3-1 >>> - Update to 3.3.3 >>> >>> * Tue Jan 31 2006 Christopher Aillon - 3.3.2-1 >>> - Update to 3.3.2 >>> >>> * Tue Jan 24 2006 Paul Nasrat - 3.2.8-1 >>> - Add --enable-threadsafe (Nicholas Miell) >>> - Update to 3.2.8 >>> >>> >>> >> This update killed my yum. I tried removing all the metadata and >> reinstalling yum but it didn't help. When it starts importing the >> metadata files yum keeps allocating memory and does nothing. >> I don't know if other have this problem but be careful. I ran f-spot and >> beagle after so I can't revert sqlite because of the database upgrade. >> >> Bart >> >> >> > Check this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179547 > I've downgraded sqlite but I had to remove f-spot and beagle for that because of the database schema upgrade. Bart -- Bart Vanbrabant PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From wrrhdev at riede.org Wed Feb 1 11:46:58 2006 From: wrrhdev at riede.org (Willem Riede) Date: Wed, 01 Feb 2006 06:46:58 -0500 Subject: open office fails to start this week In-Reply-To: (from ndbecker2@gmail.com on Tue Jan 31 22:16:43 2006) References: Message-ID: <1138794418l.26638l.1l@athena.riede.org> On 01/31/2006 10:16:43 PM, Neal Becker wrote: > sean wrote: > > > on amd64, open office refuses to start. The Open Office blue > > splash box comes up, then it dies. Same result from > > oowriter ooimpress oocalc, and > > /usr/lib/openoffice.org2.0/program/soffice. > > > > openoffice.org-core-2.0.1.1-8.2 > > openoffice.org-writer-2.0.1.1-8.2 > > openoffice.org-calc-2.0.1.1-8.2 > > openoffice.org-impress-2.0.1.1-8.2 > > > > It worked last week! > > > > Anybody else seeing this? > > > > sean > > > Lot of problems with new kernels on x86_64 with threads. Try an older > kernel. Old enough for you? [wriede at athena ~]$ uname -a Linux athena.riede.org 2.6.15-1.1826.2.10_FC5 #1 SMP Wed Jan 11 18:13:37 EST 2006 x86_64 x86_64 x86_64 GNU/Linux I don't think that theory flies (I upgraded only openoffice, not the kernel since it last worked). Regards, Willem Riede. From mailinglists at erwinrol.com Wed Feb 1 13:31:39 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 01 Feb 2006 14:31:39 +0100 Subject: blender problem Message-ID: <1138800699.7984.1.camel@xpc.home.erwinrol.com> Does anybody else have the following blender (the 3D package that is ;-P problem ? $ blender blender: symbol lookup error: /usr/lib64/libopenal.so.0: undefined symbol: MixAudio16_MMX_9 - Erwin From sundaram at fedoraproject.org Wed Feb 1 13:35:31 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 01 Feb 2006 19:05:31 +0530 Subject: blender problem In-Reply-To: <1138800699.7984.1.camel@xpc.home.erwinrol.com> References: <1138800699.7984.1.camel@xpc.home.erwinrol.com> Message-ID: <43E0B923.5070800@fedoraproject.org> Erwin Rol wrote: >Does anybody else have the following blender (the 3D package that is ;-P >problem ? > >$ blender >blender: symbol lookup error: /usr/lib64/libopenal.so.0: undefined >symbol: MixAudio16_MMX_9 > >- Erwin > > > > Which version of Blender and where did you get it from? Which version of Fedora? -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From mailinglists at erwinrol.com Wed Feb 1 13:46:52 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 01 Feb 2006 14:46:52 +0100 Subject: blender problem In-Reply-To: <43E0B923.5070800@fedoraproject.org> References: <1138800699.7984.1.camel@xpc.home.erwinrol.com> <43E0B923.5070800@fedoraproject.org> Message-ID: <1138801612.7984.4.camel@xpc.home.erwinrol.com> On Wed, 2006-02-01 at 19:05 +0530, Rahul Sundaram wrote: > >$ blender > >blender: symbol lookup error: /usr/lib64/libopenal.so.0: undefined > >symbol: MixAudio16_MMX_9 > Which version of Blender and where did you get it from? Which version of > Fedora? This is on the lastest Rawhide. rpm -qi blender Name : blender Relocations: (not relocatable) Version : 2.41 Vendor: (none) Release : 1.fc5 Build Date: Sun 29 Jan 2006 10:03:00 PM CET Install Date: Tue 31 Jan 2006 01:54:38 PM CET Build Host: hammer3.fedora.redhat.com Group : Applications/Multimedia Source RPM: blender-2.41-1.fc5.src.rpm Size : 13094125 License: GPL Signature : DSA/SHA1, Tue 31 Jan 2006 03:51:59 AM CET, Key ID 82ed95041ac70ce6 URL : http://www.blender.org Summary : 3D modeling, animation, rendering and post-production Description : Blender is the essential software solution you need for 3D, from modeling, animation, rendering and post-production to interactive creation and playback. Professionals and novices can easily and inexpensively publish stand-alone, secure, multi-platform content to the web, CD-ROMs, and other media. rpm -qi openal-0.0.8-2.fc5 Name : openal Relocations: (not relocatable) Version : 0.0.8 Vendor: (none) Release : 2.fc5 Build Date: Tue 31 Jan 2006 12:13:17 AM CET Install Date: Tue 31 Jan 2006 01:54:36 PM CET Build Host: hammer3.fedora.redhat.com Group : System Environment/Libraries Source RPM: openal-0.0.8-2.fc5.src.rpm Size : 355943 License: LGPL Signature : DSA/SHA1, Tue 31 Jan 2006 03:51:55 AM CET, Key ID 82ed95041ac70ce6 URL : http://www.openal.org/ Summary : Open Audio Library Description : OpenAL is an audio library designed in the spirit of OpenGL--machine independent, cross platform, and data format neutral, with a clean, simple C-based API. From fedora at adslpipe.co.uk Wed Feb 1 13:49:36 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Wed, 01 Feb 2006 13:49:36 +0000 Subject: blender problem In-Reply-To: <1138801612.7984.4.camel@xpc.home.erwinrol.com> References: <1138800699.7984.1.camel@xpc.home.erwinrol.com><43E0B923.5070800@fedoraproject.org> <1138801612.7984.4.camel@xpc.home.erwinrol.com> Message-ID: <43E0BC70.9010001@adslpipe.co.uk> Erwin Rol wrote: > On Wed, 2006-02-01 at 19:05 +0530, Rahul Sundaram wrote: > >> Which version of Blender and where did you get it from? Which version of >> Fedora? > > This is on the lastest Rawhide. blender is from extras, not from core .... From cmadams at hiwaay.net Wed Feb 1 14:04:58 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 1 Feb 2006 08:04:58 -0600 Subject: Make hardlinking kernel-devel optional In-Reply-To: <1138770167.5123.0.camel@laptopd505.fenrus.org> References: <20060131194417.6d7e411e@dhcp05.addix.net> <20060131222114.GD29937@redhat.com> <20060201012603.GC1210517@hiwaay.net> <20060201014831.GS16557@redhat.com> <1138770167.5123.0.camel@laptopd505.fenrus.org> Message-ID: <20060201140458.GA1088921@hiwaay.net> Once upon a time, Arjan van de Ven said: > On Tue, 2006-01-31 at 20:48 -0500, Dave Jones wrote: > > > Another though: why the "find | while ; do hardlink"? You should just > > > be able to do: > > > > > > if [ -x /usr/sbin/hardlink ] ; then > > > /usr/sbin/hardlink /usr/src/kernels/*FC* > > > fi > > > > > > The post script is forking hardlink over 5000 times as well as causing > > > thousands of repeated directory lookups by find and the shell (that > > > hardlink then has to do anyway), instead of just letting one run of > > > hardlink do its job (it should recurse just fine). > > > > I've often wondered why it was written that way too. > > Arjan, do you recall? > > if you have too many kernels, the direct commandline approach overflows > the maximum length. The current script has exactly the same problem then: if [ -x /usr/sbin/hardlink ] ; then pushd /usr/src/kernels/2.6.15-1.1884_FC5-i686 > /dev/null /usr/bin/find . -type f | while read f; do hardlink -c /usr/src/kernels/*FC*/$f $f ; done popd > /dev/null fi The "*FC*" bit is in there as well; there is no difference with what I posted above. If you want to avoid wildcards, just do: if [ -x /usr/sbin/hardlink ] ; then /usr/sbin/hardlink /usr/src/kernels fi and let anyone that installs their own kernel source under there get hardlinked as well. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From mailinglists at erwinrol.com Wed Feb 1 14:07:12 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 01 Feb 2006 15:07:12 +0100 Subject: blender problem In-Reply-To: <43E0BC70.9010001@adslpipe.co.uk> References: <1138800699.7984.1.camel@xpc.home.erwinrol.com> <43E0B923.5070800@fedoraproject.org> <1138801612.7984.4.camel@xpc.home.erwinrol.com> <43E0BC70.9010001@adslpipe.co.uk> Message-ID: <1138802832.7984.11.camel@xpc.home.erwinrol.com> On Wed, 2006-02-01 at 13:49 +0000, Andy Burns wrote: > Erwin Rol wrote: > > > On Wed, 2006-02-01 at 19:05 +0530, Rahul Sundaram wrote: > > > >> Which version of Blender and where did you get it from? Which version of > >> Fedora? > > > > This is on the lastest Rawhide. > > blender is from extras, not from core .... Yes extras for RawHide :-) But yes, this should have gone to one of the zillion other fedora list. There are just to many fedora mailing lists, and there is no fedora-extras-devel-list, just a fedora-extras-list, so i mistakenly assumed a development issue for fedora should be mailed to fedora-devel-list. - Erwin From sundaram at fedoraproject.org Wed Feb 1 14:08:55 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 01 Feb 2006 19:38:55 +0530 Subject: blender problem In-Reply-To: <1138802832.7984.11.camel@xpc.home.erwinrol.com> References: <1138800699.7984.1.camel@xpc.home.erwinrol.com> <43E0B923.5070800@fedoraproject.org> <1138801612.7984.4.camel@xpc.home.erwinrol.com> <43E0BC70.9010001@adslpipe.co.uk> <1138802832.7984.11.camel@xpc.home.erwinrol.com> Message-ID: <43E0C0F7.6010903@fedoraproject.org> Hi >Yes extras for RawHide :-) > >But yes, this should have gone to one of the zillion other fedora list. >There are just to many fedora mailing lists, and there is no >fedora-extras-devel-list, just a fedora-extras-list, so i mistakenly >assumed a development issue for fedora should be mailed to >fedora-devel-list. > >- Erwin > > If it is a straightforward bug report then just file it in http://bugzilla.redhat.com -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From mailinglists at erwinrol.com Wed Feb 1 14:37:33 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 01 Feb 2006 15:37:33 +0100 Subject: blender problem In-Reply-To: <43E0C0F7.6010903@fedoraproject.org> References: <1138800699.7984.1.camel@xpc.home.erwinrol.com> <43E0B923.5070800@fedoraproject.org> <1138801612.7984.4.camel@xpc.home.erwinrol.com> <43E0BC70.9010001@adslpipe.co.uk> <1138802832.7984.11.camel@xpc.home.erwinrol.com> <43E0C0F7.6010903@fedoraproject.org> Message-ID: <1138804653.7984.13.camel@xpc.home.erwinrol.com> On Wed, 2006-02-01 at 19:38 +0530, Rahul Sundaram wrote: > If it is a straightforward bug report then just file it in http://bugzilla.redhat.com done: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179568 - Erwin From gilboad at gmail.com Wed Feb 1 14:39:56 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 01 Feb 2006 16:39:56 +0200 Subject: Fedora Core 4 Test Update: udev-071-0.FC4.2 In-Reply-To: <20060201142811.GA15157@devserv.devel.redhat.com> References: <200601311644.k0VGii110321@int-mx1.corp.redhat.com> <43E0BD11.60308@feuerpokemon.de> <1138803993.7598.31.camel@gilboa-work-dev> <20060201142811.GA15157@devserv.devel.redhat.com> Message-ID: <1138804796.7598.37.camel@gilboa-work-dev> On Wed, 2006-02-01 at 09:28 -0500, Alan Cox wrote: > On Wed, Feb 01, 2006 at 04:26:33PM +0200, Gilboa Davara wrote: > > > hda: task_in_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } > > > hda: task_in_intr: error=0x10 { SectorIdNotFound }, LBAsect=78221567, > > > sector=78156288 > > What size is /dev/hda > The OP had IDE unknown request problems. I'm getting kernel OOPs since when using the latest kernel + -test udev combo. (on a SCSI MD5 setup) With the older udev, machine was stable. I'll post a complete bug report later this week. Gilboa From gilboad at gmail.com Wed Feb 1 15:23:37 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 01 Feb 2006 17:23:37 +0200 Subject: Mock works on i386, does nothing in x86_64. Message-ID: <1138807418.7598.50.camel@gilboa-work-dev> Hello All, I'm trying to get a x86_64 mock setup working for both FC4/5 and CentOS4. I've downloaded the latest mock src.rpm package, rebuilt it for FC4/x86_64 and installed it. If /etc/mock/default.cfrg points to the i386 configuration, mock init works just fine. If it points to the x86_64 configuration, mock init does nothing. [] $ mock --debug init DEBUG: ensuring dir /var/lib/mock/fedora-4-x86_64-core/state [] $ Any ideas? Gilboa From pjones at redhat.com Wed Feb 1 15:42:08 2006 From: pjones at redhat.com (Peter Jones) Date: Wed, 01 Feb 2006 10:42:08 -0500 Subject: Make hardlinking kernel-devel optional In-Reply-To: <20060201002534.GO16557@redhat.com> References: <20060131194417.6d7e411e@dhcp05.addix.net> <20060131222114.GD29937@redhat.com> <1138752353.24298.6.camel@ignacio.lan> <20060201002534.GO16557@redhat.com> Message-ID: <1138808528.26281.0.camel@localhost.localdomain> On Tue, 2006-01-31 at 19:25 -0500, Dave Jones wrote: > Removing the Prereq: /usr/sbin/hardlink from the spec (which I just did in CVS) > should have the effect that you can now rpm -e hardlink, and it'll > do what you want, whilst leaving it enabled for users by default. Yeah, but that sucks, because I want hardlink for things that *really* take lots of space. (like, you know, mirroring rawhide for 2 or 3 days) -- Peter From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 1 15:53:00 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 1 Feb 2006 16:53:00 +0100 Subject: Make hardlinking kernel-devel optional In-Reply-To: <1138808528.26281.0.camel@localhost.localdomain> References: <20060131194417.6d7e411e@dhcp05.addix.net> <20060131222114.GD29937@redhat.com> <1138752353.24298.6.camel@ignacio.lan> <20060201002534.GO16557@redhat.com> <1138808528.26281.0.camel@localhost.localdomain> Message-ID: <20060201165300.1ff3934e@python2> Peter Jones wrote : > On Tue, 2006-01-31 at 19:25 -0500, Dave Jones wrote: > > > Removing the Prereq: /usr/sbin/hardlink from the spec (which I just did in CVS) > > should have the effect that you can now rpm -e hardlink, and it'll > > do what you want, whilst leaving it enabled for users by default. > > Yeah, but that sucks, because I want hardlink for things that *really* > take lots of space. > > (like, you know, mirroring rawhide for 2 or 3 days) Install hardlink++ ... it's even faster! :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1656_FC4 Load : 0.17 0.31 0.26 From tadams-lists at myrealbox.com Wed Feb 1 15:57:37 2006 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Wed, 01 Feb 2006 08:57:37 -0700 Subject: Make hardlinking kernel-devel optional In-Reply-To: <20060131222114.GD29937@redhat.com> References: <20060131194417.6d7e411e@dhcp05.addix.net> <20060131222114.GD29937@redhat.com> Message-ID: <1138809458.3177.6.camel@aurora.localdomain> On Tue, 2006-01-31 at 17:21 -0500, Dave Jones wrote: > On Tue, Jan 31, 2006 at 07:44:17PM +0100, Ralf Ertzinger wrote: > > Hi. > > > > I't like to request to make the hardlink stage kernel-devel does on every > > install optional. It takes a damn lot of time on my not-too-fast machines, > > I do not exactly care about the saved disk space, and given the rate of > > kernel changes in rawhide there are a lot of wasted CPU cycles there. > > only if you have a huge number of kernels installed, which shouldn't be the case. This is not entirely true. I have a K6-2 500 with 256 M of memory. It takes FOREVER to install or remove a kernel when there are only 1 or 2 installed. It is about the only thing that takes forever. Trever -- "What makes his world so hard to see clearly is not its strangeness but its usualness. Familiarity can blind you." -- Robert M. Pirsig From fedora at camperquake.de Wed Feb 1 16:01:24 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 1 Feb 2006 17:01:24 +0100 Subject: Make hardlinking kernel-devel optional In-Reply-To: <20060201014831.GS16557@redhat.com> References: <20060131194417.6d7e411e@dhcp05.addix.net> <20060131222114.GD29937@redhat.com> <20060201012603.GC1210517@hiwaay.net> <20060201014831.GS16557@redhat.com> Message-ID: <20060201170124.2852d78d@dhcp05.addix.net> Hi. On Tue, 31 Jan 2006 20:48:31 -0500, Dave Jones wrote: > I'll merge Ignacio's change to source /etc/sysconfig/kernel, in > addition to the other change, Thank you. From davej at redhat.com Wed Feb 1 16:05:13 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 1 Feb 2006 11:05:13 -0500 Subject: Make hardlinking kernel-devel optional In-Reply-To: <1138809458.3177.6.camel@aurora.localdomain> References: <20060131194417.6d7e411e@dhcp05.addix.net> <20060131222114.GD29937@redhat.com> <1138809458.3177.6.camel@aurora.localdomain> Message-ID: <20060201160513.GB5875@redhat.com> On Wed, Feb 01, 2006 at 08:57:37AM -0700, Trever L. Adams wrote: > On Tue, 2006-01-31 at 17:21 -0500, Dave Jones wrote: > > On Tue, Jan 31, 2006 at 07:44:17PM +0100, Ralf Ertzinger wrote: > > > Hi. > > > > > > I't like to request to make the hardlink stage kernel-devel does on every > > > install optional. It takes a damn lot of time on my not-too-fast machines, > > > I do not exactly care about the saved disk space, and given the rate of > > > kernel changes in rawhide there are a lot of wasted CPU cycles there. > > > > only if you have a huge number of kernels installed, which shouldn't be the case. > > This is not entirely true. I have a K6-2 500 with 256 M of memory. It > takes FOREVER to install or remove a kernel when there are only 1 or 2 > installed. It is about the only thing that takes forever. Removing hardlink will speed up installation/removal of 'kernel-devel', not 'kernel'. That's not going to get any faster, just due to the amount of data that has to be written. Dave From dcbw at redhat.com Wed Feb 1 16:12:49 2006 From: dcbw at redhat.com (Dan Williams) Date: Wed, 01 Feb 2006 11:12:49 -0500 Subject: Mock works on i386, does nothing in x86_64. In-Reply-To: <1138807418.7598.50.camel@gilboa-work-dev> References: <1138807418.7598.50.camel@gilboa-work-dev> Message-ID: <1138810370.7268.10.camel@localhost.localdomain> On Wed, 2006-02-01 at 17:23 +0200, Gilboa Davara wrote: > Hello All, > > I'm trying to get a x86_64 mock setup working for both FC4/5 and > CentOS4. > I've downloaded the latest mock src.rpm package, rebuilt it for > FC4/x86_64 and installed it. > If /etc/mock/default.cfrg points to the i386 configuration, mock init > works just fine. > If it points to the x86_64 configuration, mock init does nothing. > > [] $ mock --debug init > DEBUG: ensuring dir /var/lib/mock/fedora-4-x86_64-core/state > > [] $ > > Any ideas? strace it... what's it doing? strace -p Dan From gilboad at gmail.com Wed Feb 1 16:12:06 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 01 Feb 2006 18:12:06 +0200 Subject: Mock works on i386, does nothing in x86_64. In-Reply-To: <1138807418.7598.50.camel@gilboa-work-dev> References: <1138807418.7598.50.camel@gilboa-work-dev> Message-ID: <1138810326.7598.62.camel@gilboa-work-dev> On Wed, 2006-02-01 at 17:23 +0200, Gilboa Davara wrote: > Hello All, > > I'm trying to get a x86_64 mock setup working for both FC4/5 and > CentOS4. > I've downloaded the latest mock src.rpm package, rebuilt it for > FC4/x86_64 and installed it. > If /etc/mock/default.cfrg points to the i386 configuration, mock init > works just fine. > If it points to the x86_64 configuration, mock init does nothing. > > [] $ mock --debug init > DEBUG: ensuring dir /var/lib/mock/fedora-4-x86_64-core/state > > [] $ > > Any ideas? > > Gilboa > > Permission problems with mock group. Please ignore. Gilboa From tadams-lists at myrealbox.com Wed Feb 1 16:45:15 2006 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Wed, 01 Feb 2006 09:45:15 -0700 Subject: Make hardlinking kernel-devel optional In-Reply-To: <20060201160513.GB5875@redhat.com> References: <20060131194417.6d7e411e@dhcp05.addix.net> <20060131222114.GD29937@redhat.com> <1138809458.3177.6.camel@aurora.localdomain> <20060201160513.GB5875@redhat.com> Message-ID: <1138812315.3177.17.camel@aurora.localdomain> On Wed, 2006-02-01 at 11:05 -0500, Dave Jones wrote: > On Wed, Feb 01, 2006 at 08:57:37AM -0700, Trever L. Adams wrote: > > This is not entirely true. I have a K6-2 500 with 256 M of memory. It > > takes FOREVER to install or remove a kernel when there are only 1 or 2 > > installed. It is about the only thing that takes forever. > > Removing hardlink will speed up installation/removal of 'kernel-devel', > not 'kernel'. That's not going to get any faster, just due to the > amount of data that has to be written. > > Dave > Well, ps xa says that it is spending ALL of its time in hardlinking. However, as you say... Trever -- "God is real, unless declared integer." -- Unknown From pjones at redhat.com Wed Feb 1 17:23:42 2006 From: pjones at redhat.com (Peter Jones) Date: Wed, 01 Feb 2006 12:23:42 -0500 Subject: Make hardlinking kernel-devel optional In-Reply-To: <20060201165300.1ff3934e@python2> References: <20060131194417.6d7e411e@dhcp05.addix.net> <20060131222114.GD29937@redhat.com> <1138752353.24298.6.camel@ignacio.lan> <20060201002534.GO16557@redhat.com> <1138808528.26281.0.camel@localhost.localdomain> <20060201165300.1ff3934e@python2> Message-ID: <1138814622.26281.3.camel@localhost.localdomain> On Wed, 2006-02-01 at 16:53 +0100, Matthias Saou wrote: > Peter Jones wrote : > > > On Tue, 2006-01-31 at 19:25 -0500, Dave Jones wrote: > > > > > Removing the Prereq: /usr/sbin/hardlink from the spec (which I just did in CVS) > > > should have the effect that you can now rpm -e hardlink, and it'll > > > do what you want, whilst leaving it enabled for users by default. > > > > Yeah, but that sucks, because I want hardlink for things that *really* > > take lots of space. > > > > (like, you know, mirroring rawhide for 2 or 3 days) > > Install hardlink++ ... it's even faster! :-) You're not wrong, but this suggestion is ignoring the point. The point was that having the kernel's %post decide you do or don't want something based on if an unrelated package is installed isn't a good plan at all. -- Peter From tadams-lists at myrealbox.com Wed Feb 1 17:41:45 2006 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Wed, 01 Feb 2006 10:41:45 -0700 Subject: Kernel issues In-Reply-To: <1124857055.11846.0.camel@aurora.localdomain> References: <1124857055.11846.0.camel@aurora.localdomain> Message-ID: <1138815705.3177.20.camel@aurora.localdomain> http://www.netfilter.org/projects/iptables/files/changes-iptables-1.3.5.txt states that in 1.3.4 the state and conntrack modules for ipv6 were enabled. http://archives.free.net.ph/message/20060118.061509.2b74ef18.en.html seems to suggest that the kernel now has it enabled. Is there any reason why Fedora Rawhide still does not have iptables conntracking and state matching for ipv6? Trever Adams On Tue, 2005-08-23 at 22:17 -0600, Trever L. Adams wrote: > During the FC4 development cycle I mistakenly asked for 2.6.12 to be > included because it "had" the ip_conntrack for ipv6. This was based on > something I read. It turns out the person was misquoting. The USAGI > project was promising this for a patch for 2.6.12. It was never included > at least to my knowledge. > > My wish list for FC5 includes the following: > TARPIT target for IPTABLES (I think it is already included). > > connlimit (and friends) matching for the kernel, this exists in > documentation but has not yet made the mainstream kernel. Help should be > given to get it there and it should be included. > > ip6_conntrack (or whatever it's name is) should be given similar help > and should be included. > > Other than that, most of my wishes are ready being addressed. I do think > these are very important for both desktop and server/firewall machines. > > Thank you, > Trever Adams > -- > "I conceive that a great part of the miseries of mankind are brought > upon them by the false estimates they have made of the value of things." > -- Benjamin Franklin > -- "When they took the fourth amendment, I was quiet because I didn't deal drugs. When they took the sixth amendment, I was quiet because I was innocent. When they took the second amendment, I was quiet because I didn't own a gun. Now they've taken the first amendment, and I can say nothing about it." -- Tim Freeman From davej at redhat.com Wed Feb 1 18:03:35 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 1 Feb 2006 13:03:35 -0500 Subject: Make hardlinking kernel-devel optional In-Reply-To: <1138814622.26281.3.camel@localhost.localdomain> References: <20060131194417.6d7e411e@dhcp05.addix.net> <20060131222114.GD29937@redhat.com> <1138752353.24298.6.camel@ignacio.lan> <20060201002534.GO16557@redhat.com> <1138808528.26281.0.camel@localhost.localdomain> <20060201165300.1ff3934e@python2> <1138814622.26281.3.camel@localhost.localdomain> Message-ID: <20060201180335.GA18059@redhat.com> On Wed, Feb 01, 2006 at 12:23:42PM -0500, Peter Jones wrote: > On Wed, 2006-02-01 at 16:53 +0100, Matthias Saou wrote: > > Peter Jones wrote : > > > > > On Tue, 2006-01-31 at 19:25 -0500, Dave Jones wrote: > > > > > > > Removing the Prereq: /usr/sbin/hardlink from the spec (which I just did in CVS) > > > > should have the effect that you can now rpm -e hardlink, and it'll > > > > do what you want, whilst leaving it enabled for users by default. > > > > > > Yeah, but that sucks, because I want hardlink for things that *really* > > > take lots of space. > > > > > > (like, you know, mirroring rawhide for 2 or 3 days) > > > > Install hardlink++ ... it's even faster! :-) > > You're not wrong, but this suggestion is ignoring the point. > > The point was that having the kernel's %post decide you do or don't want > something based on if an unrelated package is installed isn't a good > plan at all. so now you can leave it installed, and put HARDLINK="no" in your /etc/sysconfig/kernel Dave From davej at redhat.com Wed Feb 1 18:05:18 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 1 Feb 2006 13:05:18 -0500 Subject: Make hardlinking kernel-devel optional In-Reply-To: <1138812315.3177.17.camel@aurora.localdomain> References: <20060131194417.6d7e411e@dhcp05.addix.net> <20060131222114.GD29937@redhat.com> <1138809458.3177.6.camel@aurora.localdomain> <20060201160513.GB5875@redhat.com> <1138812315.3177.17.camel@aurora.localdomain> Message-ID: <20060201180518.GB18059@redhat.com> On Wed, Feb 01, 2006 at 09:45:15AM -0700, Trever L. Adams wrote: > > > This is not entirely true. I have a K6-2 500 with 256 M of memory. It > > > takes FOREVER to install or remove a kernel when there are only 1 or 2 > > > installed. It is about the only thing that takes forever. > > > > Removing hardlink will speed up installation/removal of 'kernel-devel', > > not 'kernel'. That's not going to get any faster, just due to the > > amount of data that has to be written. > > Well, ps xa says that it is spending ALL of its time in hardlinking. During -devel install yes, but you mentioned the actual 'kernel' package. The %post for the kernel doesn't do any hardlinking at all, and hasn't for a long time. Dave From pnasrat at redhat.com Wed Feb 1 20:29:30 2006 From: pnasrat at redhat.com (Paul Nasrat) Date: Wed, 01 Feb 2006 15:29:30 -0500 Subject: python sqlite issue was Re: rawhide report: 20060201 changes In-Reply-To: <43E09AAA.2000708@zoeloelip.be> References: <200602010839.k118dcOp016672@porkchop.devel.redhat.com> <43E098B4.8000604@zoeloelip.be> <43E099FF.2060402@fedoraproject.org> <43E09AAA.2000708@zoeloelip.be> Message-ID: <1138825771.4703.3.camel@enki.eridu> On Wed, 2006-02-01 at 12:25 +0100, Bart Vanbrabant wrote: > Rahul Sundaram wrote: > > Bart Vanbrabant wrote: > > > >>> sqlite-3.3.3-1 > > Check this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179547 > > > I've downgraded sqlite but I had to remove f-spot and beagle for that > because of the database schema upgrade. I've just built a python-sqlite that will fix this. Paul From zboszor at freemail.hu Wed Feb 1 22:19:06 2006 From: zboszor at freemail.hu (Zoltan Boszormenyi) Date: Wed, 01 Feb 2006 23:19:06 +0100 Subject: Question about Fedora Extras 5 Message-ID: <43E133DA.8040605@freemail.hu> Hi, will there be a CD series or DVD distribution of Fedora Extras 5, too? E.g. after installing final Core 5, Anaconda or firstboot may offer a choice about "Install Extra CDs". I just installed RHEL3 on a machine at my workplace, it had this option. Best regards, Zolt?n B?sz?rm?nyi From benjy.grogan at gmail.com Wed Feb 1 22:31:03 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Wed, 1 Feb 2006 17:31:03 -0500 Subject: XGL Message-ID: I hear that in a week or so Novell will be releasing the source code to XGL for X11 7.0. Will it be possible to have XGL available in Extras for FC5? I'm guessing it's one of those new X11 modules that v7.0 is all about. But I know little about XGL and would like to test it out to know more. It's going to be in NLD 10 in a few months. Benji -------------- next part -------------- An HTML attachment was scrubbed... URL: From dax at gurulabs.com Wed Feb 1 23:04:07 2006 From: dax at gurulabs.com (Dax Kelson) Date: Wed, 01 Feb 2006 16:04:07 -0700 Subject: Rawhide performance? Message-ID: <1138835047.3324.91.camel@mentorng.gurulabs.com> I installed rawhide on a beefy desktop computer. AMD FX-55 CPU 2GB RAM 300GB SATA RAID1 (testing out the new dmraid integration) Nvidia 6800GT 256MB video (Qty 2 -- SLI) 1600x1200 resolution I haven't quantified it yet, but desktop GNOME performance seems very sluggish. Many seconds to launch apps. Many seconds for the GNOME panel menu to drop down and populate with icons. In general the lack of performance is bad enough to be very noticeable and annoying. Is this to be expected? Is it cario? Is it the compiler settings? Is it kernel compile settings (is there lots of debug turned on)? Is it the stock nvidia driver? (nvidia proprietary driver won't install) Dax Kelson From naheemzaffar at gmail.com Wed Feb 1 23:37:57 2006 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Wed, 1 Feb 2006 23:37:57 +0000 Subject: Rawhide performance? In-Reply-To: <1138835047.3324.91.camel@mentorng.gurulabs.com> References: <1138835047.3324.91.camel@mentorng.gurulabs.com> Message-ID: <3adc77210602011537l5d8d9683u15ad71eda6a08f0a@mail.gmail.com> Adding a further question, should I file a bug against the combined rad-hat menu? it waits til it is first clicked on to check for updates. The Gnome default menu (three buttons applications, and the other two) seems to work straight away. It has probably something to do with caching, as I believe gnome was looking into adding cache's for its menu? or maybe it is regenerated with the startup of gnome? (then the redhat menu should also be regenereated at ots startup.) The combined menu seems to have got faster since yesterday I think... but it still takes a noticeable amount of time, as (I assume) it is looking for the desktop files after being clicked on for the first time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at adslpipe.co.uk Wed Feb 1 23:44:23 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Wed, 01 Feb 2006 23:44:23 +0000 Subject: XGL In-Reply-To: References: Message-ID: <43E147D7.8060902@adslpipe.co.uk> Benjy Grogan wrote: > I hear that in a week or so Novell will be releasing the source code to > XGL for X11 7.0. Well David Reveman released a snapshot about a month ago http://lists.freedesktop.org/archives/xorg/2006-January/011922.html > Will it be possible to have XGL available in Extras > for FC5? From what I understand the new code has/is being worked back into the xorg tree by Dave Airlie (and others?) but there are various xgl/xegl/xserver/kdrive trees to take into account, as well as the public work that was going on while novell were doing the behind-closed-doors work, and at the moment I think it only works using nested X servers, my *GUESS* is that it won't see the light of before X11R7.1 at the *EARLIEST* > I'm guessing it's one of those new X11 modules that v7.0 is > all about. But I know little about XGL and would like to test it out to > know more. It's going to be in NLD 10 in a few months. Modular X is designed to help thuis sort of thing, but it's not minor what you're asking for, I think you need to wait for FC6 or later ... From ellson at research.att.com Thu Feb 2 00:02:09 2006 From: ellson at research.att.com (John Ellson) Date: Wed, 01 Feb 2006 19:02:09 -0500 Subject: Rawhide performance? In-Reply-To: <1138835047.3324.91.camel@mentorng.gurulabs.com> References: <1138835047.3324.91.camel@mentorng.gurulabs.com> Message-ID: <43E14C01.7050503@research.att.com> Dax Kelson wrote: > I installed rawhide on a beefy desktop computer. > > AMD FX-55 CPU > 2GB RAM > 300GB SATA RAID1 (testing out the new dmraid integration) > Nvidia 6800GT 256MB video (Qty 2 -- SLI) > 1600x1200 resolution > > I haven't quantified it yet, but desktop GNOME performance seems very > sluggish. Many seconds to launch apps. Many seconds for the GNOME panel > menu to drop down and populate with icons. In general the lack of > performance is bad enough to be very noticeable and annoying. > > Is this to be expected? > > Is it cario? > Is it the compiler settings? > Is it kernel compile settings (is there lots of debug turned on)? > Is it the stock nvidia driver? (nvidia proprietary driver won't install) > > Dax Kelson > > There have been some sluggish kernels recently because of some debugging code, the latest kernel-2.6.15-1.1884_FC5 seems OK. There have been some problems with font caching recently. I understand that these should be fixed soon. You might check your raid performance with "hdparm -Tt /dev/md0" I'm using 4 way striping on 10Krpm SATA drives (SW RAID 0) on an X2 and I'm getting a very snappy 237MB/sec for disk reads. RAID-1 will buy you protection against disk failure, but it doesn't do much for performance. John From mharris at mharris.ca Thu Feb 2 00:52:43 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Wed, 01 Feb 2006 19:52:43 -0500 Subject: AC_PATH_XTRA vs modular xorg In-Reply-To: <1138641747.3384.7.camel@localhost> References: <1138641747.3384.7.camel@localhost> Message-ID: <43E157DB.7000809@mharris.ca> Toshio Kuratomi wrote: > Does AC_PATH_XTRA (an autoconf macro used in configure.ac to figure out > X library and include paths) cause problems with modular xorg? From the > autoconf info page it looks like it uses xmkmf to work its magic. Is > this information current? If so, this would leave me with several > options: > > 1) BuildRequire: imake This will bring in xmkmf so that AC_PATH_XTRA > will work. Since xmkmf and imake are on the way out and pkgconfig is on > the way in, this doesn't seem like the right thing to do. > > 2) In the package's spec, use: > %configure --x-includes/x-libraries= > This seems to be driving in the right direction but isn't suitable for > sending upstream. > > 3) Modify the configure.ac to use pkg-config. In order to go upstream, > this would need some sort of conditional in order to do a traditional > AC_PATH_X type check in case of older X releases. > > Have other people run into this type of problem in their packages yet? > Any pointers to a better way of handling it? Modular Xorg does not use imake or xmkmf for any part of its development or build process. imake/xmkmf and related utilities and config files are provided in X11R7 solely for the use of 3rd party legacy software which hasn't yet transitioned to the world of GNU autotools. Keep in mind though, that the focus is on autotools in the X.Org community nowadays, and the imake config files supplied in X11R7 are not very useable without a lot of distribution level customization and tweaking. Also, imake is considered to be deprecated nowadays by X.Org, so it is very highly likely to bitrot very very quickly over the next year or so. As such, all developers out there are encouraged to transition any software projects from the imake system, to GNU autotools, or some other alternative buildsystem, as imake is officially an "unmaintained" quantity now. Within a year or two, it won't be surprising to see imake becoming completely non-functional, however that's just my own personal opinion. I could be completely wrong, and maybe we'll see a hoard of feverish Motif developers come out of the woodwork and take over the imake system or something. ;o) Anyhow, I just thought I'd share that, and jump on the opportunity to both inform developers of the bleak future of imake, and to encourage early transition to alternatives while the time is ripe. Hope this is useful... -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From jspaleta at gmail.com Wed Feb 1 23:23:33 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 1 Feb 2006 18:23:33 -0500 Subject: Rawhide performance? In-Reply-To: <1138835047.3324.91.camel@mentorng.gurulabs.com> References: <1138835047.3324.91.camel@mentorng.gurulabs.com> Message-ID: <604aa7910602011523q10ba7edfha2a945e9473ac85c@mail.gmail.com> On 2/1/06, Dax Kelson wrote: > Is it kernel compile settings (is there lots of debug turned on)? you should be able to find discussion in the lists of recent vintage regarding kernel debugging impacting performance. And a grep DEBUG.*=y /boot/config-2.6.15-1.1884_FC5 is always enlightening compared to an fc4 kernel. -jef"CONFIG_DEBUG_VM=y"spaleta From mharris at mharris.ca Thu Feb 2 01:10:07 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Wed, 01 Feb 2006 20:10:07 -0500 Subject: XGL In-Reply-To: References: Message-ID: <43E15BEF.3070405@mharris.ca> Benjy Grogan wrote: > I hear that in a week or so Novell will be releasing the source code to > XGL for X11 7.0. Will it be possible to have XGL available in Extras > for FC5? I'm guessing it's one of those new X11 modules that v7.0 is > all about. But I know little about XGL and would like to test it out to > know more. It's going to be in NLD 10 in a few months. There are a lot of X related "goodies" that are up and coming in the X development world, including technologies being developed by Red Hat, Novell, Sun, and various others in the community. The current plan for Fedora Core 5, is to ship X11R7.0 as the official X implementation, including the Xorg X server. The various developmental/experimental technologies being developed by the above parties will most likely be available to Fedora users in one form or another over time, however everything is quite experimental at the current point in time to make any solid speculation for the inclusion of other components into Fedora Core 5 at this time. Either way, anything not included in Core, will very likely either end up in Fedora Extras, or rpm packaged in some other experimental repository, making it available for Fedora users to play with. Keep in mind, both end users and developers alike are equally anticipating the various new eye-candy technologies, and the X.Org community is pretty close knit. As such, you can expect that there'll be lots of fun stuff to play with in the not distant future. ;o) As various bits and pieces become less experimental, and more ready for people to play with, myself or someone else will likely post more information on this list and/or on the developmental X.Org and/or Fedora IRC channels. For now though, patience is a virtue. ;o) HTH -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From kloczek at zie.pg.gda.pl Thu Feb 2 01:56:14 2006 From: kloczek at zie.pg.gda.pl (=?UTF-8?Q?Tomasz_K=C5=82oczko?=) Date: Thu, 2 Feb 2006 02:56:14 +0100 (CET) Subject: kernel: broken qla support Message-ID: More than few kernel package version ago was broken support for all Qlogic cards. This ahppens because someone was disable all CONFIG_SCSI_QLA* in .config. [root at boss boot]# diff -u config-2.6.14-1.1773_FC5 config-2.6.15-1.1884_FC5 | grep QLA -CONFIG_SCSI_QLA2XXX=m -CONFIG_SCSI_QLA21XX=m -CONFIG_SCSI_QLA22XX=m -CONFIG_SCSI_QLA2300=m -CONFIG_SCSI_QLA2322=m -CONFIG_SCSI_QLA6312=m -CONFIG_SCSI_QLA24XX=m +CONFIG_SCSI_QLA_FC=m +# CONFIG_SCSI_QLA2XXX_EMBEDDED_FIRMWARE is not set On my system without loading qla2300 isn't possible scan avalaible LUNs. kloczek -- ----------------------------------------------------------- *Ludzie nie maj? problem?w, tylko sobie sami je stwarzaj?* ----------------------------------------------------------- Tomasz K?oczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek at rudy.mif.pg.gda.pl* From davej at redhat.com Thu Feb 2 02:10:45 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 1 Feb 2006 21:10:45 -0500 Subject: kernel: broken qla support In-Reply-To: References: Message-ID: <20060202021045.GI5875@redhat.com> On Thu, Feb 02, 2006 at 02:56:14AM +0100, Tomasz K?oczko wrote: > > More than few kernel package version ago was broken support for all Qlogic > cards. This ahppens because someone was disable all CONFIG_SCSI_QLA* in > .config. > > [root at boss boot]# diff -u config-2.6.14-1.1773_FC5 config-2.6.15-1.1884_FC5 | grep QLA > -CONFIG_SCSI_QLA2XXX=m > -CONFIG_SCSI_QLA21XX=m > -CONFIG_SCSI_QLA22XX=m > -CONFIG_SCSI_QLA2300=m > -CONFIG_SCSI_QLA2322=m > -CONFIG_SCSI_QLA6312=m > -CONFIG_SCSI_QLA24XX=m > +CONFIG_SCSI_QLA_FC=m > +# CONFIG_SCSI_QLA2XXX_EMBEDDED_FIRMWARE is not set > > On my system without loading qla2300 isn't possible scan avalaible LUNs. In 2.6.16rc, CONFIG_SCSI_QLA2XXX_EMBEDDED_FIRMWARE is marked as deprecated, which means at some point it's going to go away completely. The help for that option states.. This option offers you the deprecated firmware-loader modules that have been obsoleted by the usage of the Firmware Loader interface in the qla2xxx driver. But I realise now this means that right now, we aren't shipping the firmware at all with this disabled. I'll have a talk with the upstream people responsible, and see what the plans here are. Can you file a bugzilla on this so that it doesn't get lost, and make it block on FC5Blocker please ? Dave From kloczek at zie.pg.gda.pl Thu Feb 2 02:28:37 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=) Date: Thu, 02 Feb 2006 03:28:37 +0100 Subject: yum memory leak ? Message-ID: <1138847317.11799.3.camel@kloczek01.pracownicy.zie> Im just finish some partial upgrades. During this yum was upgraded. After finish this I'm run again yum and .. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 25053 root 18 0 5879m 1.3g 1148 R 9 33.9 2:36.81 yum ^^^^^ kloczek From caillon at redhat.com Thu Feb 2 03:50:59 2006 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 01 Feb 2006 22:50:59 -0500 Subject: yum memory leak ? In-Reply-To: <1138847317.11799.3.camel@kloczek01.pracownicy.zie> References: <1138847317.11799.3.camel@kloczek01.pracownicy.zie> Message-ID: <43E181A3.3030502@redhat.com> On 02/01/2006 09:28 PM, Tomasz K?oczko wrote: > Im just finish some partial upgrades. During this yum was upgraded. > After finish this I'm run again yum and .. > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 25053 root 18 0 5879m 1.3g 1148 R 9 33.9 2:36.81 yum > ^^^^^ > > kloczek > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179547 python-sqlite bug. Get the updated python-sqlite package in tomorrow's rawhide (might have to install it manually with rpm -Fvh first) From mailinglists at erwinrol.com Thu Feb 2 03:55:07 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Thu, 02 Feb 2006 04:55:07 +0100 Subject: /usr/bin/gcj-dbtool problem Message-ID: <1138852508.7984.23.camel@xpc.home.erwinrol.com> Hey all, For a while i have the the problem that /usr/bin/gcj-dbtool hangs until i kill it. This is a problem because most java packages use it in their %pre and %post script, and so all installs (and updates) of java programs like eclipse and openoffice hang. After removing all java stuff and reinstalling I think i found the cause of the problem, or atleast the RPM that causes the problem. Before installing eclipse-cdt i can run /usr/bin/rebuild-gcj-db (this calls gcj-dbtool in the end) without a problem. After I install eclipse-cdt /usr/bin/rebuild-gcj-db will hang and ps ax will show the following. 14594 pts/0 S+ 0:00 /bin/bash /usr/bin/rebuild-gcj-db 14614 pts/0 S+ 0:00 xargs -0 /usr/bin/gcj-dbtool -m /usr/lib64/gcj-4.1.0/classmap.db /usr/lib64/gcj-4.1.0/classmap.db 14615 pts/0 Sl+ 0:00 /usr/bin/gcj-dbtool -m /usr/lib64/gcj-4.1.0/classmap.db /usr/lib64/gcj-4.1.0/classmap.db /usr/lib64/gcj/eclipse-cdt/cdtmakeui.jar.db /usr/lib64/gcj/eclipse-cdt/cdtmicore.1 The yum install/update will hang untill i do "kill 14615", than it continues like this Running Transaction Installing: eclipse-cdt ######################### [1/1] xargs: /usr/bin/gcj-dbtool: terminated by signal 15 Installed: eclipse-cdt.x86_64 1:3.0.1-1jpp_3fc Complete! >From now on every packages that uses /usr/bin/rebuild-gcj-db will hang yum/rpm when it is being installed or uninstalled. Removing the eclipse-cdt rpm fixes the problem again. - Erwin From overholt at redhat.com Thu Feb 2 04:11:20 2006 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 1 Feb 2006 23:11:20 -0500 Subject: /usr/bin/gcj-dbtool problem In-Reply-To: <1138852508.7984.23.camel@xpc.home.erwinrol.com> References: <1138852508.7984.23.camel@xpc.home.erwinrol.com> Message-ID: <20060202041120.GA794@redhat.com> CCing Andrew Haley * Erwin Rol [2006-02-01 22:55]: > > For a while i have the the problem that /usr/bin/gcj-dbtool hangs until > i kill it. This is a problem because most java packages use it in their > %pre and %post script, and so all installs (and updates) of java > programs like eclipse and openoffice hang. I believe Andrew Haley was tracking this down. I don't think it has anything to do with the CDT. Andrew From dcbw at redhat.com Thu Feb 2 05:11:26 2006 From: dcbw at redhat.com (Dan Williams) Date: Thu, 02 Feb 2006 00:11:26 -0500 Subject: /usr/bin/gcj-dbtool problem In-Reply-To: <20060202041120.GA794@redhat.com> References: <1138852508.7984.23.camel@xpc.home.erwinrol.com> <20060202041120.GA794@redhat.com> Message-ID: <1138857086.18976.7.camel@localhost.localdomain> On Wed, 2006-02-01 at 23:11 -0500, Andrew Overholt wrote: > CCing Andrew Haley > > * Erwin Rol [2006-02-01 22:55]: > > > > For a while i have the the problem that /usr/bin/gcj-dbtool hangs until > > i kill it. This is a problem because most java packages use it in their > > %pre and %post script, and so all installs (and updates) of java > > programs like eclipse and openoffice hang. > > I believe Andrew Haley was tracking this down. I don't think it has > anything to do with the CDT. I was having a problem with this once with mock and the Extras buildsystem, and we thought the cause might have been python <= 2.3, which masks _all_ signals for new threads. Somebody said that gcj uses signals for thread control, which may have lead to a deadlock waiting for a thread to exit when the signal was simply ignored due to python stupidity. Not sure if signal masks have anything to do with rpm, but it seemed to be the issue with python <= 2.3. Dan From sundaram at fedoraproject.org Thu Feb 2 06:26:42 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Feb 2006 11:56:42 +0530 Subject: Rawhide performance? In-Reply-To: <3adc77210602011537l5d8d9683u15ad71eda6a08f0a@mail.gmail.com> References: <1138835047.3324.91.camel@mentorng.gurulabs.com> <3adc77210602011537l5d8d9683u15ad71eda6a08f0a@mail.gmail.com> Message-ID: <43E1A622.2070704@fedoraproject.org> Naheem Zaffar wrote: > Adding a further question, should I file a bug against the combined > rad-hat menu? it waits til it is first clicked on to check for > updates. The Gnome default menu (three buttons applications, and the > other two) seems to work straight away. Which updates? > > It has probably something to do with caching, as I believe gnome was > looking into adding cache's for its menu? or maybe it is regenerated > with the startup of gnome? (then the redhat menu should also be > regenereated at ots startup.) > > The combined menu seems to have got faster since yesterday I think... > but it still takes a noticeable amount of time, as (I assume) it is > looking for the desktop files after being clicked on for the first time. How many seconds of difference is there between the RH menu and the stock GNOME menu? -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From mailinglists at erwinrol.com Thu Feb 2 09:22:36 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Thu, 02 Feb 2006 10:22:36 +0100 Subject: /usr/bin/gcj-dbtool problem In-Reply-To: <1138857086.18976.7.camel@localhost.localdomain> References: <1138852508.7984.23.camel@xpc.home.erwinrol.com> <20060202041120.GA794@redhat.com> <1138857086.18976.7.camel@localhost.localdomain> Message-ID: <1138872156.7984.28.camel@xpc.home.erwinrol.com> On Thu, 2006-02-02 at 00:11 -0500, Dan Williams wrote: > On Wed, 2006-02-01 at 23:11 -0500, Andrew Overholt wrote: > > CCing Andrew Haley > > > > * Erwin Rol [2006-02-01 22:55]: > > > > > > For a while i have the the problem that /usr/bin/gcj-dbtool hangs until > > > i kill it. This is a problem because most java packages use it in their > > > %pre and %post script, and so all installs (and updates) of java > > > programs like eclipse and openoffice hang. > > > > I believe Andrew Haley was tracking this down. I don't think it has > > anything to do with the CDT. > > I was having a problem with this once with mock and the Extras > buildsystem, and we thought the cause might have been python <= 2.3, > which masks _all_ signals for new threads. Somebody said that gcj uses > signals for thread control, which may have lead to a deadlock waiting > for a thread to exit when the signal was simply ignored due to python > stupidity. Not sure if signal masks have anything to do with rpm, but > it seemed to be the issue with python <= 2.3. > I don't think /usr/bin/rebuild-gcj-db or /usr/bin/rebuild-gcj-db have anything to do with python, so i doubt it is a python issue. and secondly the rawhide python version is 2.4.2. But a deadlock might be the cause, because when i hang strace on the program it seems to wait on a futex. - Erwin From teg at pvv.org Thu Feb 2 09:25:35 2006 From: teg at pvv.org (=?UTF-8?B?VHJvbmQgRWl2aW5kIEdsb21zcsO4ZA==?=) Date: Thu, 02 Feb 2006 10:25:35 +0100 Subject: Rawhide performance? In-Reply-To: <1138835047.3324.91.camel@mentorng.gurulabs.com> References: <1138835047.3324.91.camel@mentorng.gurulabs.com> Message-ID: <43E1D00F.2040807@pvv.org> Dax Kelson wrote: > I installed rawhide on a beefy desktop computer. > > AMD FX-55 CPU > 2GB RAM > 300GB SATA RAID1 (testing out the new dmraid integration) > Nvidia 6800GT 256MB video (Qty 2 -- SLI) > 1600x1200 resolution > > I haven't quantified it yet, but desktop GNOME performance seems very > sluggish. Many seconds to launch apps. Many seconds for the GNOME panel > menu to drop down and populate with icons. In general the lack of > performance is bad enough to be very noticeable and annoying. > > One trick which improved performance from what you describe to ok for me, was rerunning fc-cache - I had a directory of fonts in my home directory, and it seemed to parse them every time something started. From fedora at adslpipe.co.uk Thu Feb 2 10:36:46 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Thu, 02 Feb 2006 10:36:46 +0000 Subject: nothing from buildsys? Message-ID: <43E1E0BE.2080908@adslpipe.co.uk> Is buildsys still working on today's bake, or is there some other reason why no new rawhide today? From mailinglists at erwinrol.com Thu Feb 2 10:39:35 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Thu, 02 Feb 2006 11:39:35 +0100 Subject: /usr/bin/gcj-dbtool problem In-Reply-To: <1138857086.18976.7.camel@localhost.localdomain> References: <1138852508.7984.23.camel@xpc.home.erwinrol.com> <20060202041120.GA794@redhat.com> <1138857086.18976.7.camel@localhost.localdomain> Message-ID: <1138876776.7984.31.camel@xpc.home.erwinrol.com> On Thu, 2006-02-02 at 00:11 -0500, Dan Williams wrote: > On Wed, 2006-02-01 at 23:11 -0500, Andrew Overholt wrote: > > CCing Andrew Haley > > > > * Erwin Rol [2006-02-01 22:55]: > > > > > > For a while i have the the problem that /usr/bin/gcj-dbtool hangs until > > > i kill it. This is a problem because most java packages use it in their > > > %pre and %post script, and so all installs (and updates) of java > > > programs like eclipse and openoffice hang. > > > > I believe Andrew Haley was tracking this down. I don't think it has > > anything to do with the CDT. > > I was having a problem with this once with mock and the Extras > buildsystem, and we thought the cause might have been python <= 2.3, > which masks _all_ signals for new threads. Somebody said that gcj uses > signals for thread control, which may have lead to a deadlock waiting > for a thread to exit when the signal was simply ignored due to python > stupidity. Not sure if signal masks have anything to do with rpm, but > it seemed to be the issue with python <= 2.3. > I don't know if it helps, but here is a back trace of /usr/bin/gcj-dbtool. Also keep in mind this is on x86_64, which i forgot to mention earlier. (gdb) info threads 2 Thread 1084229984 (LWP 16734) 0x0000003e1d009436 in ?? () from /lib64/libpthread.so.0 1 Thread 47043201282672 (LWP 16733) 0x0000003e1d00b01d in ?? () from /lib64/libpthread.so.0 (gdb) thread 1 [Switching to thread 1 (Thread 47043201282672 (LWP 16733))]#0 0x0000003e1d00b01d in ?? () from /lib64/libpthread.so.0 (gdb) bt #0 0x0000003e1d00b01d in ?? () from /lib64/libpthread.so.0 #1 0x00002ac9189c3dc3 in GC_stop_world () from /usr/lib/../lib64/libgcj.so.7 #2 0x00002ac9189b63bb in GC_stopped_mark () from /usr/lib/../lib64/libgcj.so.7 #3 0x00002ac9189b66fb in GC_try_to_collect_inner () from /usr/lib/../lib64/libgcj.so.7 #4 0x00002ac9189b6960 in GC_collect_or_expand () from /usr/lib/../lib64/libgcj.so.7 #5 0x00002ac9189b6e5b in GC_allocobj () from /usr/lib/../lib64/libgcj.so.7 #6 0x00002ac9189badb0 in GC_generic_malloc_inner () from /usr/lib/../lib64/libgcj.so.7 #7 0x00002ac9189bb7f7 in GC_generic_malloc_many () from /usr/lib/../lib64/libgcj.so.7 #8 0x00002ac9189c31a4 in GC_local_malloc_atomic () from /usr/lib/../lib64/libgcj.so.7 #9 0x00002ac918509ec7 in _Jv_NewPrimArray () from /usr/lib/../lib64/libgcj.so.7 #10 0x00002ac918559074 in gnu::gcj::runtime::PersistentByteMap::getBytes () from /usr/lib/../lib64/libgcj.so.7 #11 0x00002ac9185591a2 in gnu::gcj::runtime::PersistentByteMap$HashIterator::next () from /usr/lib/../lib64/libgcj.so.7 #12 0x00002ac918558e86 in gnu::gcj::runtime::PersistentByteMap::putAll () from /usr/lib/../lib64/libgcj.so.7 #13 0x0000000000404592 in ?? () #14 0x00002ac918532483 in gnu::java::lang::MainThread::call_main () from /usr/lib/../lib64/libgcj.so.7 #15 0x00002ac91853f5ca in _Jv_ThreadRun () from /usr/lib/../lib64/libgcj.so.7 #16 0x00002ac91850ad4b in _Jv_RunMain () from /usr/lib/../lib64/libgcj.so.7 #17 0x0000003e1be1cde4 in __libc_start_main (main=0x402cc0, argc=168, ubp_av=0x7fffff98f658, init=Variable "init" is not available. ) at libc-start.c:231 #18 0x0000000000402c49 in ?? () #19 0x00007fffff98f648 in ?? () #20 0x0000000000000000 in ?? () (gdb) thread 2 [Switching to thread 2 (Thread 1084229984 (LWP 16734))]#0 0x0000003e1d009436 in ?? () from /lib64/libpthread.so.0 (gdb) bt #0 0x0000003e1d009436 in ?? () from /lib64/libpthread.so.0 #1 0x00002ac918545992 in _Jv_CondWait () from /usr/lib/../lib64/libgcj.so.7 #2 0x00002ac918531da4 in gnu::gcj::runtime::FinalizerThread::run () from /usr/lib/../lib64/libgcj.so.7 #3 0x00002ac91853f5ca in _Jv_ThreadRun () from /usr/lib/../lib64/libgcj.so.7 #4 0x00002ac918545521 in _Jv_ThreadRegister () from /usr/lib/../lib64/libgcj.so.7 #5 0x00002ac9189c339e in GC_start_routine () from /usr/lib/../lib64/libgcj.so.7 #6 0x0000003e1d00615a in start_thread (arg=Variable "arg" is not available. ) at pthread_create.c:261 #7 0x0000003e1bec92bd in ?? () from /lib64/libc.so.6 #8 0x0000000000000000 in ?? () From pbrobinson at gmail.com Thu Feb 2 10:39:38 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 2 Feb 2006 10:39:38 +0000 Subject: nothing from buildsys? In-Reply-To: <43E1E0BE.2080908@adslpipe.co.uk> References: <43E1E0BE.2080908@adslpipe.co.uk> Message-ID: <5256d0b0602020239s3aa68266p37346bfc4d493c12@mail.gmail.com> > Is buildsys still working on today's bake, or is there some other reason > why no new rawhide today? If there's a lot of rebuilds it sometimes doesn't appear until around midday GMT time so it's probably still toiling away on the builds. I saw on a blog somewhere that one of the redhat guys is playing with a unified accross all platforms srpm repo so it could be due to that. Pete From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 2 10:51:12 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 2 Feb 2006 11:51:12 +0100 Subject: Question about Fedora Extras 5 In-Reply-To: <43E133DA.8040605@freemail.hu> References: <43E133DA.8040605@freemail.hu> Message-ID: <20060202115112.78e641de@python2> Zoltan Boszormenyi wrote : > will there be a CD series or DVD distribution of Fedora Extras 5, too? > E.g. after installing final Core 5, Anaconda or firstboot may offer a choice > about "Install Extra CDs". > > I just installed RHEL3 on a machine at my workplace, it had this option. I already asked the same a few weeks back : http://www.redhat.com/archives/fedora-devel-list/2006-January/msg00389.html Also, I still haven't received any feedback about the FC4 Extra CD of freshrpms.net packages I created, in case you'd be interested in trying it out (as it seems no one else has... the audience on mailing-list is not the best one for "use this if you don't have Internet" stuff, I guess ;-)) : http://www.mail-archive.com/freshrpms-list at freshrpms.net/msg01137.html But I think you're confusing the terms "Extra CDs" and "Fedora Extras", which are two completely different things, although it would definitely be nice to make "Extra CDs/DVDs of Fedora Extras" at some point. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1656_FC4 Load : 0.17 0.53 0.39 From sundaram at fedoraproject.org Thu Feb 2 10:56:28 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Feb 2006 16:26:28 +0530 Subject: Question about Fedora Extras 5 In-Reply-To: <20060202115112.78e641de@python2> References: <43E133DA.8040605@freemail.hu> <20060202115112.78e641de@python2> Message-ID: <43E1E55C.8070806@fedoraproject.org> Hi > >But I think you're confusing the terms "Extra CDs" and "Fedora Extras", >which are two completely different things, although it would definitely be >nice to make "Extra CDs/DVDs of Fedora Extras" at some point. > >Matthias > > It expect that it requires a Fedora Extras "release" and a good amount of coordination to make this happen. I dont think it is merely a matter of lumping together a set of packages into a ISO image -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 2 11:05:32 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 2 Feb 2006 12:05:32 +0100 Subject: Question about Fedora Extras 5 In-Reply-To: <43E1E55C.8070806@fedoraproject.org> References: <43E133DA.8040605@freemail.hu> <20060202115112.78e641de@python2> <43E1E55C.8070806@fedoraproject.org> Message-ID: <20060202120532.7ad09981@python2> Rahul Sundaram wrote : > >But I think you're confusing the terms "Extra CDs" and "Fedora Extras", > >which are two completely different things, although it would definitely be > >nice to make "Extra CDs/DVDs of Fedora Extras" at some point. > > > It expect that it requires a Fedora Extras "release" and a good amount > of coordination to make this happen. I dont think it is merely a matter > of lumping together a set of packages into a ISO image Well, I don't see an Extras "release" as a requirement, as I don't "release" freshrpms.net either. Just clearly document a set of packages, create the the meta stuff you needs (.xml, scripts), and you can create a very useful snapshot at any given time. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1656_FC4 Load : 0.26 0.26 0.33 From sundaram at fedoraproject.org Thu Feb 2 11:13:26 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Feb 2006 16:43:26 +0530 Subject: Question about Fedora Extras 5 In-Reply-To: <20060202120532.7ad09981@python2> References: <43E133DA.8040605@freemail.hu> <20060202115112.78e641de@python2> <43E1E55C.8070806@fedoraproject.org> <20060202120532.7ad09981@python2> Message-ID: <43E1E956.9020202@fedoraproject.org> Matthias Saou wrote: >Rahul Sundaram wrote : > > > >>>But I think you're confusing the terms "Extra CDs" and "Fedora Extras", >>>which are two completely different things, although it would definitely be >>>nice to make "Extra CDs/DVDs of Fedora Extras" at some point. >>> >>> >>> >>It expect that it requires a Fedora Extras "release" and a good amount >>of coordination to make this happen. I dont think it is merely a matter >>of lumping together a set of packages into a ISO image >> >> > >Well, I don't see an Extras "release" as a requirement, as I don't >"release" freshrpms.net either. Just clearly document a set of packages, >create the the meta stuff you needs (.xml, scripts), and you can create a >very useful snapshot at any given time. > > So is this process documented? Can it be automated so a Extras ISO image is created every few weeks or so for example?. During the Fedora development process many of the packages in Extras seem to remain broken for a longer time than the ones in core which led to the impression for me that a release would be required to ensure that the packages work as expected. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 2 11:28:24 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 2 Feb 2006 12:28:24 +0100 Subject: Question about Fedora Extras 5 In-Reply-To: <43E1E956.9020202@fedoraproject.org> References: <43E133DA.8040605@freemail.hu> <20060202115112.78e641de@python2> <43E1E55C.8070806@fedoraproject.org> <20060202120532.7ad09981@python2> <43E1E956.9020202@fedoraproject.org> Message-ID: <20060202122824.05b702d3@python2> Rahul Sundaram wrote : > >>>But I think you're confusing the terms "Extra CDs" and "Fedora Extras", > >>>which are two completely different things, although it would definitely be > >>>nice to make "Extra CDs/DVDs of Fedora Extras" at some point. > >>> > >>> > >>> > >>It expect that it requires a Fedora Extras "release" and a good amount > >>of coordination to make this happen. I dont think it is merely a matter > >>of lumping together a set of packages into a ISO image > >> > >> > > > >Well, I don't see an Extras "release" as a requirement, as I don't > >"release" freshrpms.net either. Just clearly document a set of packages, > >create the the meta stuff you needs (.xml, scripts), and you can create a > >very useful snapshot at any given time. > > > > > So is this process documented? Can it be automated so a Extras ISO > image is created every few weeks or so for example?. During the Fedora > development process many of the packages in Extras seem to remain broken > for a longer time than the ones in core which led to the impression for > me that a release would be required to ensure that the packages work as > expected. In this particular case, just look at the current Extras as Rawhide, and an eventual frozen set of packages as a Fedora Core release. Would seem pretty trivial to me to freeze a set of Extras packages, test release it as CD/DVD a few times, fixing all the major bugs and dependency problems found (in both Extras and this frozen set), then releasing a final media. The ongoing parallel life of Extras continues the whole time, might even benefit from the extra testing, and people with no or slow Internet connections can then have an easier way of installing Extras packages at one point. This is what I did for the freshrpms CD I made. As an example, the extra testing that came from making the CD uncovered a few bugs, like the summary line of my ipw2x00-firmware packages that wasn't UTF-8 encoded, thus didn't show up properly. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1656_FC4 Load : 0.19 0.20 0.26 From n0dalus+redhat at gmail.com Thu Feb 2 11:37:40 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Thu, 2 Feb 2006 22:07:40 +1030 Subject: Question about Fedora Extras 5 In-Reply-To: <20060202122824.05b702d3@python2> References: <43E133DA.8040605@freemail.hu> <20060202115112.78e641de@python2> <43E1E55C.8070806@fedoraproject.org> <20060202120532.7ad09981@python2> <43E1E956.9020202@fedoraproject.org> <20060202122824.05b702d3@python2> Message-ID: <6280325c0602020337p41a0ed71g9490130f3e495aeb@mail.gmail.com> On 2/2/06, Matthias Saou wrote: > > In this particular case, just look at the current Extras as Rawhide, and > an eventual frozen set of packages as a Fedora Core release. Would seem > pretty trivial to me to freeze a set of Extras packages, test release it > as CD/DVD a few times, fixing all the major bugs and dependency problems > found (in both Extras and this frozen set), then releasing a final media. > The ongoing parallel life of Extras continues the whole time, might even > benefit from the extra testing, and people with no or slow Internet > connections can then have an easier way of installing Extras packages at > one point. > I know lots of people that have 28/56k internet connections that I want to give Fedora to, but it's a lot of effort for them to wait for hundreds of MB of updates. Would it be possible to provide updates-released CDs as well, even as part of an automated process? A bonus would be to have a way to install these updates on an already installed system. n0dalus. From sundaram at fedoraproject.org Thu Feb 2 11:39:00 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Feb 2006 17:09:00 +0530 Subject: Question about Fedora Extras 5 In-Reply-To: <20060202122824.05b702d3@python2> References: <43E133DA.8040605@freemail.hu> <20060202115112.78e641de@python2> <43E1E55C.8070806@fedoraproject.org> <20060202120532.7ad09981@python2> <43E1E956.9020202@fedoraproject.org> <20060202122824.05b702d3@python2> Message-ID: <43E1EF54.4070209@fedoraproject.org> Hi >In this particular case, just look at the current Extras as Rawhide, and >an eventual frozen set of packages as a Fedora Core release. Would seem >pretty trivial to me to freeze a set of Extras packages, test release it >as CD/DVD a few times, fixing all the major bugs and dependency problems >found (in both Extras and this frozen set), then releasing a final media. >The ongoing parallel life of Extras continues the whole time, might even >benefit from the extra testing, and people with no or slow Internet >connections can then have an easier way of installing Extras packages at >one point. > > Yes, a freeze and testing period is what I called a Fedora Extras release. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From sundaram at fedoraproject.org Thu Feb 2 11:44:13 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Feb 2006 17:14:13 +0530 Subject: Question about Fedora Extras 5 In-Reply-To: <6280325c0602020337p41a0ed71g9490130f3e495aeb@mail.gmail.com> References: <43E133DA.8040605@freemail.hu> <20060202115112.78e641de@python2> <43E1E55C.8070806@fedoraproject.org> <20060202120532.7ad09981@python2> <43E1E956.9020202@fedoraproject.org> <20060202122824.05b702d3@python2> <6280325c0602020337p41a0ed71g9490130f3e495aeb@mail.gmail.com> Message-ID: <43E1F08D.6080104@fedoraproject.org> Hi >I know lots of people that have 28/56k internet connections that I >want to give Fedora to, but it's a lot of effort for them to wait for >hundreds of MB of updates. Would it be possible to provide >updates-released CDs as well, even as part of an automated process? A >bonus would be to have a way to install these updates on an already >installed system. > Updates-release CD for core or extras or both?. Any additional release would require additional QA to ensure that updates arent merely trading one set of bugs for another. See earlier discussions in the list for details. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From mail-lists at karan.org Thu Feb 2 11:48:51 2006 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 02 Feb 2006 11:48:51 +0000 Subject: Question about Fedora Extras 5 In-Reply-To: <43E1E956.9020202@fedoraproject.org> References: <43E133DA.8040605@freemail.hu> <20060202115112.78e641de@python2> <43E1E55C.8070806@fedoraproject.org> <20060202120532.7ad09981@python2> <43E1E956.9020202@fedoraproject.org> Message-ID: <43E1F1A3.6040903@karan.org> Rahul Sundaram wrote: >> Well, I don't see an Extras "release" as a requirement, as I don't >> "release" freshrpms.net either. Just clearly document a set of packages, >> create the the meta stuff you needs (.xml, scripts), and you can create a >> very useful snapshot at any given time. >> >> > So is this process documented? Can it be automated so a Extras ISO > image is created every few weeks or so for example?. During the Fedora > development process many of the packages in Extras seem to remain broken > for a longer time than the ones in core which led to the impression for > me that a release would be required to ensure that the packages work as > expected. > If there is a need to throw some time + resources behind this effort as an initial proof-of-concept, I am happy to do that ( I could knock something together fairly rapidly ). Maybe I can co-ordinate with Kevin Fenzi, and extend his ongoing efforts ( ref: https://www.redhat.com/archives/fedora-extras-list/2006-February/msg00044.html ) Also, should this conversation, at some point, move [1] to the Extras list ? - KB [1] Or atleast be echo'd on the Extras list -- Karanbir Singh : http://www.karan.org/ : 2522219 at icq From aph at redhat.com Thu Feb 2 11:49:55 2006 From: aph at redhat.com (Andrew Haley) Date: Thu, 2 Feb 2006 11:49:55 +0000 Subject: /usr/bin/gcj-dbtool problem Message-ID: <200602021158.k12BwZ4l013624@zapata.pink> Dan Williams writes: > On Wed, 2006-02-01 at 23:11 -0500, Andrew Overholt wrote: > > CCing Andrew Haley > > > > * Erwin Rol [2006-02-01 22:55]: > > > > > > For a while i have the the problem that /usr/bin/gcj-dbtool hangs until > > > i kill it. This is a problem because most java packages use it in their > > > %pre and %post script, and so all installs (and updates) of java > > > programs like eclipse and openoffice hang. > > > > I believe Andrew Haley was tracking this down. I don't think it has > > anything to do with the CDT. > > I was having a problem with this once with mock and the Extras > buildsystem, and we thought the cause might have been python <= 2.3, > which masks _all_ signals for new threads. Somebody said that gcj uses > signals for thread control, which may have lead to a deadlock waiting > for a thread to exit when the signal was simply ignored due to python > stupidity. Not sure if signal masks have anything to do with rpm, but > it seemed to be the issue with python <= 2.3. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179002 I'm pretty sure it's a kernel problem. It has never been reported on any system except Feodra, and replacing kernel 2.6.15-1.1869_FC5 with vanilla 2.6.15 (build with fedora .config) seems to fix it. Andrew. From reuben-fedora-devel at reub.net Thu Feb 2 11:59:35 2006 From: reuben-fedora-devel at reub.net (Reuben Farrelly) Date: Fri, 03 Feb 2006 00:59:35 +1300 Subject: nothing from buildsys? In-Reply-To: <5256d0b0602020239s3aa68266p37346bfc4d493c12@mail.gmail.com> References: <43E1E0BE.2080908@adslpipe.co.uk> <5256d0b0602020239s3aa68266p37346bfc4d493c12@mail.gmail.com> Message-ID: <43E1F427.3050701@reub.net> On 2/02/2006 11:39 p.m., Peter Robinson wrote: >> Is buildsys still working on today's bake, or is there some other reason >> why no new rawhide today? > > If there's a lot of rebuilds it sometimes doesn't appear until around > midday GMT time so it's probably still toiling away on the builds. I > saw on a blog somewhere that one of the redhat guys is playing with a > unified accross all platforms srpm repo so it could be due to that. Every time a nasty bug shows up in rawhide (like the one with yum and python-sqlite from yesterday) I wonder if it would be possible or in fact practical to have two builds a day or more to pick up rawhide changes. Is there a reason why only 1 a day is done - is it just historical? I'd also be curious to know what sort of machine is doing the actual building, one would expect that given sometimes there are builds of gcc and glibc on the go in one nightly build, it must be a seriously fast piece of machinery to be able to produce so many binaries in a reasonable amount of time. Anyone who has tried compiling glibc from scratch would testify how long that alone can take ;-) reuben From mailinglists at erwinrol.com Thu Feb 2 12:11:08 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Thu, 02 Feb 2006 13:11:08 +0100 Subject: /usr/bin/gcj-dbtool problem In-Reply-To: <200602021158.k12BwZ4l013624@zapata.pink> References: <200602021158.k12BwZ4l013624@zapata.pink> Message-ID: <1138882268.7984.37.camel@xpc.home.erwinrol.com> On Thu, 2006-02-02 at 11:49 +0000, Andrew Haley wrote: > Dan Williams writes: > > On Wed, 2006-02-01 at 23:11 -0500, Andrew Overholt wrote: > > > CCing Andrew Haley > > > > > > * Erwin Rol [2006-02-01 22:55]: > > > > > > > > For a while i have the the problem that /usr/bin/gcj-dbtool hangs until > > > > i kill it. This is a problem because most java packages use it in their > > > > %pre and %post script, and so all installs (and updates) of java > > > > programs like eclipse and openoffice hang. > > > > > > I believe Andrew Haley was tracking this down. I don't think it has > > > anything to do with the CDT. > > > > I was having a problem with this once with mock and the Extras > > buildsystem, and we thought the cause might have been python <= 2.3, > > which masks _all_ signals for new threads. Somebody said that gcj uses > > signals for thread control, which may have lead to a deadlock waiting > > for a thread to exit when the signal was simply ignored due to python > > stupidity. Not sure if signal masks have anything to do with rpm, but > > it seemed to be the issue with python <= 2.3. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179002 > That looks exactly like the problem i see, so i guess thats the bug. (why is it that when I search bugzilla before mailing I never find bug reports, and when I mail before searching there there already is a bug report :-) - Erwin From fedora at adslpipe.co.uk Thu Feb 2 12:25:33 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Thu, 02 Feb 2006 12:25:33 +0000 Subject: nothing from buildsys? In-Reply-To: <43E1F427.3050701@reub.net> References: <43E1E0BE.2080908@adslpipe.co.uk><5256d0b0602020239s3aa68266p37346bfc4d493c12@mail.gmail.com> <43E1F427.3050701@reub.net> Message-ID: <43E1FA3D.8060608@adslpipe.co.uk> Reuben Farrelly wrote: > Is there a reason why only 1 a day is done - is it just historical? I think some of the mirrors struggle to be less than 24h out of date :-( From ndbecker2 at gmail.com Thu Feb 2 12:26:53 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 02 Feb 2006 07:26:53 -0500 Subject: /usr/bin/gcj-dbtool problem References: <1138852508.7984.23.camel@xpc.home.erwinrol.com> <20060202041120.GA794@redhat.com> <1138857086.18976.7.camel@localhost.localdomain> <1138872156.7984.28.camel@xpc.home.erwinrol.com> Message-ID: Erwin Rol wrote: > On Thu, 2006-02-02 at 00:11 -0500, Dan Williams wrote: >> On Wed, 2006-02-01 at 23:11 -0500, Andrew Overholt wrote: >> > CCing Andrew Haley >> > >> > * Erwin Rol [2006-02-01 22:55]: >> > > >> > > For a while i have the the problem that /usr/bin/gcj-dbtool hangs >> > > until i kill it. This is a problem because most java packages use it >> > > in their %pre and %post script, and so all installs (and updates) of >> > > java programs like eclipse and openoffice hang. >> > >> > I believe Andrew Haley was tracking this down. I don't think it has >> > anything to do with the CDT. >> >> I was having a problem with this once with mock and the Extras >> buildsystem, and we thought the cause might have been python <= 2.3, >> which masks _all_ signals for new threads. Somebody said that gcj uses >> signals for thread control, which may have lead to a deadlock waiting >> for a thread to exit when the signal was simply ignored due to python >> stupidity. Not sure if signal masks have anything to do with rpm, but >> it seemed to be the issue with python <= 2.3. >> > > I don't think /usr/bin/rebuild-gcj-db or /usr/bin/rebuild-gcj-db have > anything to do with python, so i doubt it is a python issue. and > secondly the rawhide python version is 2.4.2. > > But a deadlock might be the cause, because when i hang strace on the > program it seems to wait on a futex. > > - Erwin > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179002 From n0dalus+redhat at gmail.com Thu Feb 2 12:42:58 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Thu, 2 Feb 2006 23:12:58 +1030 Subject: Question about Fedora Extras 5 In-Reply-To: <43E1F08D.6080104@fedoraproject.org> References: <43E133DA.8040605@freemail.hu> <20060202115112.78e641de@python2> <43E1E55C.8070806@fedoraproject.org> <20060202120532.7ad09981@python2> <43E1E956.9020202@fedoraproject.org> <20060202122824.05b702d3@python2> <6280325c0602020337p41a0ed71g9490130f3e495aeb@mail.gmail.com> <43E1F08D.6080104@fedoraproject.org> Message-ID: <6280325c0602020442t62b64510x8d84be66b9d174d5@mail.gmail.com> On 2/2/06, Rahul Sundaram wrote: > Hi > > >I know lots of people that have 28/56k internet connections that I > >want to give Fedora to, but it's a lot of effort for them to wait for > >hundreds of MB of updates. Would it be possible to provide > >updates-released CDs as well, even as part of an automated process? A > >bonus would be to have a way to install these updates on an already > >installed system. > > > Updates-release CD for core or extras or both?. Any additional release > would require additional QA to ensure that updates arent merely trading > one set of bugs for another. See earlier discussions in the list for > details. > Core updates. Why would it require any more QA than is currently done? It would simply be a snapshot of the updated packages at that instance of time. Just like if I had done a 'yum update' at that exact time, my system would be left in the same state. Any additional CDs would come with just as much disclaimer as having your system in any other particular state of updation. While it may in some cases be simply trading one set of bugs for another, they key difference in this case is that bandwidth required for future updates is much less if you already have your system installed using an updated set of packages. It's the difference between requiring 30mb of updates in the first month and requiring 300mb of updates in the first month. n0dalus. From sundaram at fedoraproject.org Thu Feb 2 12:51:13 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 02 Feb 2006 18:21:13 +0530 Subject: Question about Fedora Extras 5 In-Reply-To: <6280325c0602020442t62b64510x8d84be66b9d174d5@mail.gmail.com> References: <43E133DA.8040605@freemail.hu> <20060202115112.78e641de@python2> <43E1E55C.8070806@fedoraproject.org> <20060202120532.7ad09981@python2> <43E1E956.9020202@fedoraproject.org> <20060202122824.05b702d3@python2> <6280325c0602020337p41a0ed71g9490130f3e495aeb@mail.gmail.com> <43E1F08D.6080104@fedoraproject.org> <6280325c0602020442t62b64510x8d84be66b9d174d5@mail.gmail.com> Message-ID: <43E20041.9030408@fedoraproject.org> Hi >Core updates. Why would it require any more QA than is currently done? >It would simply be a snapshot of the updated packages at that instance >of time. Just like if I had done a 'yum update' at that exact time, my >system would be left in the same state. Any additional CDs would come >with just as much disclaimer as having your system in any other >particular state of updation. While it may in some cases be simply >trading one set of bugs for another, they key difference in this case >is that bandwidth required for future updates is much less if you >already have your system installed using an updated set of packages. >It's the difference between requiring 30mb of updates in the first >month and requiring 300mb of updates in the first month. > > So you dont want a respin which already includes the updates but just a updated Extra CD in addition the original GA release? -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From n0dalus+redhat at gmail.com Thu Feb 2 13:09:32 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Thu, 2 Feb 2006 23:39:32 +1030 Subject: Question about Fedora Extras 5 In-Reply-To: <43E20041.9030408@fedoraproject.org> References: <43E133DA.8040605@freemail.hu> <20060202115112.78e641de@python2> <43E1E55C.8070806@fedoraproject.org> <20060202120532.7ad09981@python2> <43E1E956.9020202@fedoraproject.org> <20060202122824.05b702d3@python2> <6280325c0602020337p41a0ed71g9490130f3e495aeb@mail.gmail.com> <43E1F08D.6080104@fedoraproject.org> <6280325c0602020442t62b64510x8d84be66b9d174d5@mail.gmail.com> <43E20041.9030408@fedoraproject.org> Message-ID: <6280325c0602020509n1c88d59cn999437cc966c5a4a@mail.gmail.com> On 2/2/06, Rahul Sundaram wrote: > > So you dont want a respin which already includes the updates but just a > updated Extra CD in addition the original GA release? > Yes, just an extra CD with updates in addition to the original release. I was just hoping that if anybody does work on making this kind of thing work for 'extras', then maybe it could be provided for core updates as well. It would be really helpful to a lot of people. Atleast how I would imagine it is: The installer would ask you to provide any additional CDs if you need to at the end of the install, and would update any available packages from the CDs, whether they be extras or core or third party. This would be great for security updates, where having a system connected to the internet for hundreds of MB of updates could leave it vulnerable for some time. n0dalus. From gilboad at gmail.com Thu Feb 2 13:19:17 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 02 Feb 2006 15:19:17 +0200 Subject: Replace mozilla with SeaMonkey? Message-ID: <1138886357.499.17.camel@gilboa-work-dev> Helllo all, With the release of the SeaMonkey 1.0, shouldn't Fedora replace the aging mozilla-1.7.x package (.12 in both rawhide and FC5T2) with the new SeaMonkey package? http://www.mozilla.org/projects/seamonkey/ Gilboa From mail-lists at karan.org Thu Feb 2 13:39:19 2006 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 02 Feb 2006 13:39:19 +0000 Subject: Question about Fedora Extras 5 In-Reply-To: <6280325c0602020509n1c88d59cn999437cc966c5a4a@mail.gmail.com> References: <43E133DA.8040605@freemail.hu> <20060202115112.78e641de@python2> <43E1E55C.8070806@fedoraproject.org> <20060202120532.7ad09981@python2> <43E1E956.9020202@fedoraproject.org> <20060202122824.05b702d3@python2> <6280325c0602020337p41a0ed71g9490130f3e495aeb@mail.gmail.com> <43E1F08D.6080104@fedoraproject.org> <6280325c0602020442t62b64510x8d84be66b9d174d5@mail.gmail.com> <43E20041.9030408@fedoraproject.org> <6280325c0602020509n1c88d59cn999437cc966c5a4a@mail.gmail.com> Message-ID: <43E20B87.1000300@karan.org> n0dalus wrote: > Atleast how I would imagine it is: The installer would ask you to > provide any additional CDs if you need to at the end of the install, > and would update any available packages from the CDs, whether they be > extras or core or third party. > the ideal situation would be if the installer could ask 'before' the install if you have any other Cd's around. And just install the updated packages in the first place. Rather than needing to install the 'usual stuff' and then having to run an update. and I believe some work is being done along these lines already. - KB -- Karanbir Singh : http://www.karan.org/ : 2522219 at icq From buildsys at redhat.com Thu Feb 2 15:53:17 2006 From: buildsys at redhat.com (Build System) Date: Thu, 2 Feb 2006 10:53:17 -0500 Subject: rawhide report: 20060202 changes Message-ID: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> Removed package sqlite2 Removed package jakarta-commons-discovery Updated Packages: GConf2-2.13.5-2 --------------- * Wed Feb 01 2006 Christopher Aillon 2.13.5-2 - Add patch from Mandriva to reload GConf2 every time a schema is added or removed (solves bug 173869) anaconda-10.91.12-1 ------------------- * Thu Feb 02 2006 Jeremy Katz - 10.91.12-1 - improves %packages section some more (clumens) - give a better error on kickstart lvm syntax errors (clumens) - display vncconnect error messages (clumens) - make swap labels shorter for cciss (dcantrel, #176074) - Make /dev/root for mkinitrd (#171662) - Use pirut stuff for graphical group selection ant-0:1.6.5-1jpp_4fc -------------------- * Thu Feb 02 2006 Archit Shah - 0:1.6.5-1jpp_4fc - build ant without using native code * Mon Jan 09 2006 Jesse Keating - 0:1.6.5-1jpp_3fc - bump again for another gcj fix arts-8:1.5.1-1 -------------- * Wed Feb 01 2006 Than Ngo 8:1.5.1-1 - 1.5.1 * Wed Jan 18 2006 Than Ngo 8:1.5.0-2 - rebuilt with --enable-new-ldflags * Mon Dec 19 2005 Than Ngo 8:1.5.0-1 - apply patch to fix #169631 autofs-1:4.1.4-16.2 ------------------- * Wed Feb 01 2006 Ian Kent - 1:4.1.4-16.2 - Add more general patch to translate "_" to "." in map names. (bz #147765) avahi-0.6.6-1 ------------- * Wed Feb 01 2006 Jason Vas Dias - 0.6.6-1 - fix bug 179448: mis-alignment of input cmsghdr msg->msg_control buffer on ia64 - Upgrade to 0.6.6 dejagnu-1:1.4.4-5 ----------------- * Thu Feb 02 2006 Petr Machata 1:1.4.4-5 - Applying H.J. Lu's race condition patch. (#166000) f-spot-0.1.8-2 -------------- * Wed Feb 01 2006 Christopher Aillon - 0.1.8-2 - Add sqlite3.patch to ensure that sqlite3 is used if both sqlite2 and sqlite3 are installed. firefox-1.5.0.1-2 ----------------- * Wed Feb 01 2006 Christopher Aillon - 1.5.0.1-2 - Update language packs to 1.5.0.1 - Add dumpstack.patch * Wed Feb 01 2006 Christopher Aillon - 1.5.0.1-1 - Update to 1.5.0.1 freeglut-2.4.0-3 ---------------- * Tue Jan 31 2006 Mike A. Harris 2.4.0-3 - Added "Requires: libGL-devel libGLU-devel" to fix bug (#179464) - Change file based GL header build dep to BuildRequires: libGL-devel * Fri Dec 09 2005 Jesse Keating 2.4.0-2.1 - rebuilt * Fri Nov 18 2005 Bill Nottingham 2.4.0-2 - Remove references to obsolete /usr/X11R6 paths gcc-4.1.0-0.19 -------------- * Wed Feb 01 2006 Jakub Jelinek 4.1.0-0.19 - s390{,x} long double patch fix for s390x ICEs on test-ldouble and tst-align2 (Andreas Krebbel) gjdoc-0.7.7-2 ------------- * Wed Feb 01 2006 Andrew Overholt 0.7.7-2 - Don't package .la files (rh#172634). - Install un-versioned symlinks in /usr/share/java (rh#177139). gnome-menus-2.13.5-4 -------------------- * Wed Feb 01 2006 Ray Strode 2.13.5-4 - don't ship upstream Desktop.directory files indent-2.2.9-11 --------------- * Wed Feb 01 2006 Petr Machata 2.2.9-11 - Setting LC_ALL instead of LC_MESSAGES in order to fix output of KOI8-R characters. (#134044) initscripts-8.24-1 ------------------ * Wed Feb 01 2006 Bill Nottingham 8.24-1 - init.d/functions: fix sendmail startup - sysconfig.txt: fix typos () kdebase-6:3.5.1-1 ----------------- * Wed Feb 01 2006 Than Ngo 6:3.5.1-1 - 3.5.1 - apply patch to fix kded segfaults for audio/blank cd's - get rid some of unneeded patches - add buildrequires on libxkbfile-devel * Thu Jan 26 2006 Than Ngo 6:3.5.0-3 - add BuildPrereq on dbus-devel >= 0.60, hal-devel >= 0.5 kdelibs-6:3.5.1-1 ----------------- * Wed Feb 01 2006 Than Ngo 6:3.5.1-1 - 3.5.1 * Thu Jan 19 2006 Than Ngo 6:3.5.0-6 - rename subpackage to -apidocs kernel-2.6.15-1.1895_FC5 ------------------------ * Wed Feb 01 2006 Dave Jones < - Woo, 2.6.16rc1-git5 (at last) - Enable exec* checking except for execmod for ppc32 and ia64 (#178747) - Disable a bunch of drivers for SBC's that won't run Fedora. - Reenable building of firmware for QLogic HBA's. - Add a bunch of missing newlines & the like to module init's. - Fix up broken DVB kobject use. - Fixed an oops in the stradis driver initialisation. - Happy Birthday to "The Yellow Dart". * Tue Jan 31 2006 Dave Jones < - Remove prereq on hardlink, making hardlinking of -devel packages optional - Further improvements to the 'dont want to hardlink' case. Now checks for HARDLINK="no" in /etc/sysconfig/kernel * Tue Jan 31 2006 Don Zickus < - Enable x86-64 kdumping, and kdump related specfile cleanup. libFS-1.0.0-2 ------------- * Mon Jan 23 2006 Mike A. Harris 1.0.0-2 - Bumped and rebuilt m17n-db-1.3.1-1 --------------- * Thu Feb 02 2006 Jens Petersen - 1.3.1-1 - update to 1.3.1 release - add new icons to language subpackages - new common-cjk subpackage for CJK common files - new Swedish subpackage - exclude new pkgconfig file openoffice.org-1:2.0.1.1-9.2 ---------------------------- * Fri Jan 27 2006 Caolan McNamara - 1:2.0.1.1-9 - add openoffice.org-2.0.2.ooo61178.ucb.neon25.patch for neon 0.25.X - missing %defattr(-,root,root) - rh#179256# if java fails (i.e. was configured to use libgcj.so.6) reconfigure to pick up libgcj.so.7 - rh#177205# add some templates, including a fedora themed presentation openssh-4.3p1-1 --------------- * Wed Feb 01 2006 Tomas Mraz - 4.3p1-1 - new version, dropped obsolete patches pam_smb-1.1.7-7 --------------- * Wed Feb 01 2006 Nalin Dahyabhai 1.1.7-7 - remove a stray quote from configure.in that was causing a syntax error and breaking recompiles (upstream #1422089) perl-4:5.8.8-1 -------------- * Wed Feb 01 2006 Jason Vas Dias - 4:5.8.8-1 - Upgrade to new upstream release 5.8.8, officially released today * Tue Jan 31 2006 Jason Vas Dias - 3:5.8.8-0.1_RC1 - fix bug 178343: h2ph must include cpp "predefined macros" in _h2ph_pre.ph - Add perl(:MODULE_COMPAT_5.8.8) to Provides - Fix perlbug patch * Fri Jan 20 2006 Jason Vas Dias - 3:5.8.8-0_RC1 - Upgrade to new upstream release candidate 5.8.8-RC1 pirut-0.9.8-1 ------------- * Thu Feb 02 2006 Jeremy Katz - 0.9.8-1 - Some fixes to single-install-packages from Tim Lauridsen (#178908) - Tweaks to the optional packages installed label (#178088, #179205) pykickstart-0.17-1 ------------------ * Wed Feb 01 2006 Chris Lumens 0.17-1 - Don't set a default port for vnc. python-sqlite-1.1.6-3 --------------------- * Wed Feb 01 2006 Paul Nasrat - 1.1.6-3 - Pass valid parameter to prepare (#179547) - Temporarily remove %check * Wed Feb 01 2006 Paul Nasrat - 1.1.6-2 - Rebuild redhat-artwork-0.235-2 ---------------------- * Mon Jan 30 2006 Ray Strode 0.235-2 - create symlinks from redhat artwork to gnome overrides redhat-menus-6.5.4-2 -------------------- * Wed Feb 01 2006 Ray Strode - 6.5.4-2 - fix applications menu * Wed Feb 01 2006 Ray Strode - 6.5.4-1 - merge /usr/local/share/applications - ship separate directory file for System menu rhpxl-0.13-1 ------------ * Wed Feb 01 2006 Chris Lumens 0.13-1 - Add aspect ratio patch from Jef Spaleta (#158143). rhythmbox-0.9.3-2 ----------------- * Wed Feb 01 2006 Christopher Aillon 0.9.3-2 - Remove hack for 173869, as its no longer needed. * Wed Feb 01 2006 Christopher Aillon 0.9.3-1 - 0.9.3 * Wed Feb 01 2006 Christopher Aillon 0.9.2.cvs20060201-1 - Newer CVS snapshot selinux-policy-2.2.9-2 ---------------------- * Wed Feb 01 2006 Dan Walsh 2.2.9-2 - Fix for spamd to use ldap * Fri Jan 27 2006 Dan Walsh 2.2.9-1 - Update to upstream system-config-soundcard-1.2.14-6 -------------------------------- * Wed Feb 01 2006 Martin Stransky 1.2.14-6 - added alsa-lib/utils log Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- ccs-devel - 1.0.2-3.1.ppc requires ccs = 0:1.0.2-3.1 gulm - 1.0.4-2.FC5.1.ppc requires ccs Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.3-2.s390 requires kernel >= 0:2.6.9-11 systemtap - 0.5.3-2.s390 requires kernel-devel Broken deps for s390x ---------------------------------------------------------- libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) systemtap - 0.5.3-2.s390x requires kernel >= 0:2.6.9-11 systemtap - 0.5.3-2.s390x requires kernel-devel Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 From kloczek at zie.pg.gda.pl Thu Feb 2 16:01:29 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=) Date: Thu, 02 Feb 2006 17:01:29 +0100 Subject: rawhide report: 20060202 changes In-Reply-To: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> Message-ID: <1138896089.15099.6.camel@kloczek01.pracownicy.zie> Dnia 02-02-2006, czw o godzinie 10:53 -0500, Build System napisa?(a): [/.\] > m17n-db-1.3.1-1 > --------------- > * Thu Feb 02 2006 Jens Petersen - 1.3.1-1 > - update to 1.3.1 release > - add new icons to language subpackages > - new common-cjk subpackage for CJK common files > - new Swedish subpackage > - exclude new pkgconfig file In last time I observe constant degradation quality of Fedora packages. Very good examle this degradation is this package. Instead generate 41 binary subpackages m17n-db* each with support for one language better will be generate one with correctly used %lang() macros in %files list. kloczek From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 2 16:24:33 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 2 Feb 2006 17:24:33 +0100 Subject: rawhide report: 20060202 changes In-Reply-To: <1138896089.15099.6.camel@kloczek01.pracownicy.zie> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> <1138896089.15099.6.camel@kloczek01.pracownicy.zie> Message-ID: <20060202172433.2a79d274@python2> Tomasz K?oczko wrote : > Dnia 02-02-2006, czw o godzinie 10:53 -0500, Build System napisa?(a): > [/.\] > > m17n-db-1.3.1-1 > > --------------- > > * Thu Feb 02 2006 Jens Petersen - 1.3.1-1 > > - update to 1.3.1 release > > - add new icons to language subpackages > > - new common-cjk subpackage for CJK common files > > - new Swedish subpackage > > - exclude new pkgconfig file > > In last time I observe constant degradation quality of Fedora packages. > Very good examle this degradation is this package. > Instead generate 41 binary subpackages m17n-db* each with support for > one language better will be generate one with correctly used %lang() > macros in %files list. I'm not sure I understood everything perfectly, but I'd have to agree about the less-than-optimal splitting, as AFAICS most of those language packages are 8kB big... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1656_FC4 Load : 0.56 0.76 0.93 From clovis at agr.unicamp.br Thu Feb 2 16:25:49 2006 From: clovis at agr.unicamp.br (Clovis Tristao) Date: Thu, 02 Feb 2006 14:25:49 -0200 Subject: Yum question Message-ID: <43E2328D.9090109@agr.unicamp.br> Hi, I have tried update the Fedora Core Rawhide, but appears this error: --> Processing Dependency: libneon.so.24 for package: openoffice.org-core --> Finished Dependency Resolution Error: Missing Dependency: libneon.so.24 is needed by package openoffice.org-core In the package list update not existe openoffice.org-core to update. What's happening? Thanks a lot, Cl?vis -- Clovis Tristao - UNICAMP/Faculdade de Engenharia Agricola Administrador de Redes - Secao de Informatica (SINFO) E-mail: mailto:clovis at agr.unicamp.br http://www.agr.unicamp.br Fone(0xx19) 37881031-37881038 ou FAX(55xx19) 37881005/37881010 From ivazquez at ivazquez.net Thu Feb 2 16:34:58 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 02 Feb 2006 11:34:58 -0500 Subject: Yum question In-Reply-To: <43E2328D.9090109@agr.unicamp.br> References: <43E2328D.9090109@agr.unicamp.br> Message-ID: <1138898098.23767.19.camel@ignacio.lan> On Thu, 2006-02-02 at 14:25 -0200, Clovis Tristao wrote: > What's happening? Exactly what's expected given the Rawhide report from yesterday. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Thu Feb 2 16:46:52 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 2 Feb 2006 11:46:52 -0500 Subject: rawhide report: 20060202 changes In-Reply-To: <20060202172433.2a79d274@python2> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> <1138896089.15099.6.camel@kloczek01.pracownicy.zie> <20060202172433.2a79d274@python2> Message-ID: <20060202164652.GA5019@devserv.devel.redhat.com> Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > Tomasz K?oczko wrote : > > > Dnia 02-02-2006, czw o godzinie 10:53 -0500, Build System napisa?(a): > > [/.\] > > > m17n-db-1.3.1-1 > > > --------------- > > > * Thu Feb 02 2006 Jens Petersen - 1.3.1-1 > > > - update to 1.3.1 release > > > - add new icons to language subpackages > > > - new common-cjk subpackage for CJK common files > > > - new Swedish subpackage > > > - exclude new pkgconfig file > > > > In last time I observe constant degradation quality of Fedora packages. > > Very good examle this degradation is this package. > > Instead generate 41 binary subpackages m17n-db* each with support for > > one language better will be generate one with correctly used %lang() > > macros in %files list. > > I'm not sure I understood everything perfectly, but I'd have to agree > about the less-than-optimal splitting, as AFAICS most of those language > packages are 8kB big... I expect it's not covered in comps right either - Jens, what's the logic behind this? Bill From alan at clueserver.org Thu Feb 2 16:51:30 2006 From: alan at clueserver.org (alan) Date: Thu, 2 Feb 2006 08:51:30 -0800 (PST) Subject: yum memory leak ? In-Reply-To: <43E181A3.3030502@redhat.com> Message-ID: On Wed, 1 Feb 2006, Christopher Aillon wrote: > On 02/01/2006 09:28 PM, Tomasz K??oczko wrote: > > Im just finish some partial upgrades. During this yum was upgraded. > > After finish this I'm run again yum and .. > > > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > > 25053 root 18 0 5879m 1.3g 1148 R 9 33.9 2:36.81 yum > > ^^^^^ > > > > kloczek > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179547 > > python-sqlite bug. Get the updated python-sqlite package in tomorrow's > rawhide (might have to install it manually with rpm -Fvh first) I figured that would get reported. I did an strace on the process. The result was a bizzare combination of "interesting" and "painful". Thanks for getting the fix out so fast. -- "George W. Bush -- Bringing back the Sixties one Nixon at a time." From gazzerh at gmail.com Thu Feb 2 17:30:13 2006 From: gazzerh at gmail.com (Garry Harthill) Date: Thu, 2 Feb 2006 17:30:13 +0000 Subject: python sqlite issue was Re: rawhide report: 20060201 changes In-Reply-To: <1138825771.4703.3.camel@enki.eridu> References: <200602010839.k118dcOp016672@porkchop.devel.redhat.com> <43E098B4.8000604@zoeloelip.be> <43E099FF.2060402@fedoraproject.org> <43E09AAA.2000708@zoeloelip.be> <1138825771.4703.3.camel@enki.eridu> Message-ID: <1fcc9e320602020930w3f052f71p@mail.gmail.com> On 01/02/06, Paul Nasrat wrote: > On Wed, 2006-02-01 at 12:25 +0100, Bart Vanbrabant wrote: > > Rahul Sundaram wrote: > > > Bart Vanbrabant wrote: > > > > > >>> sqlite-3.3.3-1 > > > > Check this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179547 > > > > > I've downgraded sqlite but I had to remove f-spot and beagle for that > > because of the database schema upgrade. > > I've just built a python-sqlite that will fix this. > > Paul Any chance you could get this out soon? :P I got a broken yum and I don't really wanna manually remove f-spot and beagle so I can downgrade sqlite. Garry From jkeating at j2solutions.net Thu Feb 2 17:42:15 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 02 Feb 2006 09:42:15 -0800 Subject: python sqlite issue was Re: rawhide report: 20060201 changes In-Reply-To: <1fcc9e320602020930w3f052f71p@mail.gmail.com> References: <200602010839.k118dcOp016672@porkchop.devel.redhat.com> <43E098B4.8000604@zoeloelip.be> <43E099FF.2060402@fedoraproject.org> <43E09AAA.2000708@zoeloelip.be> <1138825771.4703.3.camel@enki.eridu> <1fcc9e320602020930w3f052f71p@mail.gmail.com> Message-ID: <1138902136.5469.35.camel@ender> On Thu, 2006-02-02 at 17:30 +0000, Garry Harthill wrote: > Any chance you could get this out soon? :P > > I got a broken yum and I don't really wanna manually remove f-spot and > beagle so I can downgrade sqlite. > The fixed python-sqlite is in today's rawhide. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From gazzerh at gmail.com Thu Feb 2 18:27:38 2006 From: gazzerh at gmail.com (Garry Harthill) Date: Thu, 2 Feb 2006 18:27:38 +0000 Subject: python sqlite issue was Re: rawhide report: 20060201 changes In-Reply-To: <1138902136.5469.35.camel@ender> References: <200602010839.k118dcOp016672@porkchop.devel.redhat.com> <43E098B4.8000604@zoeloelip.be> <43E099FF.2060402@fedoraproject.org> <43E09AAA.2000708@zoeloelip.be> <1138825771.4703.3.camel@enki.eridu> <1fcc9e320602020930w3f052f71p@mail.gmail.com> <1138902136.5469.35.camel@ender> Message-ID: <1fcc9e320602021027x39635072g@mail.gmail.com> On 02/02/06, Jesse Keating wrote: > On Thu, 2006-02-02 at 17:30 +0000, Garry Harthill wrote: > > Any chance you could get this out soon? :P > > > > I got a broken yum and I don't really wanna manually remove f-spot and > > beagle so I can downgrade sqlite. > > > > The fixed python-sqlite is in today's rawhide. > > -- > Jesse Keating RHCE (geek.j2solutions.net) > Fedora Legacy Team (www.fedoralegacy.org) > GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) I can't seem to find it for some reason. Can you post a link to the i386 RPM please From fedora at adslpipe.co.uk Thu Feb 2 18:37:49 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Thu, 02 Feb 2006 18:37:49 +0000 Subject: python sqlite issue was Re: rawhide report: 20060201 changes In-Reply-To: <1138902136.5469.35.camel@ender> References: <200602010839.k118dcOp016672@porkchop.devel.redhat.com><43E098B4.8000604@zoeloelip.be> <43E099FF.2060402@fedoraproject.org><43E09AAA.2000708@zoeloelip.be> <1138825771.4703.3.camel@enki.eridu><1fcc9e320602020930w3f052f71p@mail.gmail.com> <1138902136.5469.35.camel@ender> Message-ID: <43E2517D.6040007@adslpipe.co.uk> Jesse Keating wrote: > The fixed python-sqlite is in today's rawhide. There hasn't "been" a today's rawhide for lots of the mirrors yet, but it is finding it's way around now ... From ndbecker2 at gmail.com Thu Feb 2 18:37:44 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 02 Feb 2006 13:37:44 -0500 Subject: anaconda request - retry on network download failure Message-ID: When using network installation, it SURE would be nice if anaconda gave a choice to retry a failed package download! From caillon at redhat.com Thu Feb 2 18:45:04 2006 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 02 Feb 2006 13:45:04 -0500 Subject: Replace mozilla with SeaMonkey? In-Reply-To: <1138886357.499.17.camel@gilboa-work-dev> References: <1138886357.499.17.camel@gilboa-work-dev> Message-ID: <43E25330.10901@redhat.com> On 02/02/2006 08:19 AM, Gilboa Davara wrote: > Helllo all, > > With the release of the SeaMonkey 1.0, shouldn't Fedora replace the > aging mozilla-1.7.x package (.12 in both rawhide and FC5T2) with the new > SeaMonkey package? > http://www.mozilla.org/projects/seamonkey/ The eventual goal is to drop the mozilla based browsers from Core and move them to Extras, so SeaMonkey should do that now. I think Kai Engert has an SRPM lying around somewhere. From alan at clueserver.org Thu Feb 2 20:37:46 2006 From: alan at clueserver.org (alan) Date: Thu, 2 Feb 2006 12:37:46 -0800 (PST) Subject: python sqlite issue was Re: rawhide report: 20060201 changes In-Reply-To: <1fcc9e320602020930w3f052f71p@mail.gmail.com> Message-ID: On Thu, 2 Feb 2006, Garry Harthill wrote: > On 01/02/06, Paul Nasrat wrote: > > On Wed, 2006-02-01 at 12:25 +0100, Bart Vanbrabant wrote: > > > Rahul Sundaram wrote: > > > > Bart Vanbrabant wrote: > > > > > > > >>> sqlite-3.3.3-1 > > > > > > Check this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179547 > > > > > > > I've downgraded sqlite but I had to remove f-spot and beagle for that > > > because of the database schema upgrade. > > > > I've just built a python-sqlite that will fix this. > > > > Paul > > Any chance you could get this out soon? :P > > I got a broken yum and I don't really wanna manually remove f-spot and > beagle so I can downgrade sqlite. I checked mirrors.kernel.org. They did not have the binary, but the src.rpm was in /fedora/code/development/SRPMS. python-sqlite-1.1.6-3 is the one you want. -- "George W. Bush -- Bringing back the Sixties one Nixon at a time." From kengert at redhat.com Thu Feb 2 20:38:53 2006 From: kengert at redhat.com (Kai Engert) Date: Thu, 02 Feb 2006 21:38:53 +0100 Subject: Replace mozilla with SeaMonkey? In-Reply-To: <43E25330.10901@redhat.com> References: <1138886357.499.17.camel@gilboa-work-dev> <43E25330.10901@redhat.com> Message-ID: <43E26DDD.5050202@redhat.com> Yes, I already worked in my spare time on producing SeaMonkey RPM packages. I selected a combination of patches from the set currently used in Firefox, Thunderbird and Mozilla RPM packages. I made it so that Mozilla and SeaMonkey can be installed at the same time. I would like to wait with publishing the package until Chris had a chance to review spec file and patches. I'll post to the list once we're done. Also note, this will be my first package for Extras, so it might take me a bit longer to get it included there. For FC 5, we think Mozilla 1.7.x should still be included. That seems reasonable as other packages might depend on Mozilla (?), and the GRE it provides (see /etc/gre.conf). I don't know whether SeaMonkey 1.0 can be used as a compatible drop-in replacement for that. It's probably not a good idea to remove Mozilla that late in the FC 5 release process. After FC 5, we might either remove Mozilla 1.7.x from Core, or move it over to Extras. But if Extras contains SeaMonkey, there might no longer be a need to provide Mozilla 1.7.x, too. Kai Christopher Aillon wrote: > On 02/02/2006 08:19 AM, Gilboa Davara wrote: >> Helllo all, >> >> With the release of the SeaMonkey 1.0, shouldn't Fedora replace the >> aging mozilla-1.7.x package (.12 in both rawhide and FC5T2) with the new >> SeaMonkey package? >> http://www.mozilla.org/projects/seamonkey/ > > The eventual goal is to drop the mozilla based browsers from Core and > move them to Extras, so SeaMonkey should do that now. I think Kai > Engert has an SRPM lying around somewhere. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3248 bytes Desc: S/MIME Cryptographic Signature URL: From kloczek at zie.pg.gda.pl Thu Feb 2 21:32:19 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=) Date: Thu, 02 Feb 2006 22:32:19 +0100 Subject: rawhide report: 20060202 changes In-Reply-To: <20060202164652.GA5019@devserv.devel.redhat.com> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> <1138896089.15099.6.camel@kloczek01.pracownicy.zie> <20060202172433.2a79d274@python2> <20060202164652.GA5019@devserv.devel.redhat.com> Message-ID: <1138915939.15099.34.camel@kloczek01.pracownicy.zie> Dnia 02-02-2006, czw o godzinie 11:46 -0500, Bill Nottingham napisa?(a): [..] > I expect it's not covered in comps right either - Jens, what's the > logic behind this? (I'm just after short review of m17n) IMO it will be better ask why m17n was included to distribution packages list. On first look m17n it is real piece of crap. Why ? Because in current form it duplicates many things from libc locale database and few more things (did I write "duplicates" ? .. correction: it is not second copy of locale/encodings description because second sits in XLOCALE [1]). If it is realy neccassary for some importand new package better will be invest more energy in (re)development this library for not bloating distribution using (IMO) discussabe quality code :> So .. question is: what is the logic is in include m17n to distribution ? Please .. do not morph Fedora to next JBDL (Just Bloated Linux Distribution (tm)). [1] more copies of charsets descriptions sits in mysql, cups (it is Common Unix Printing System so why the hell it does not uses libc ? :>), kbd (it is Linux specyfic code so .. also: why it does not uses libc charsets database ?), perl, squiremail (why it does not uses php iconv for charsets conversions ?), python, tcl and few other packages .. kloczek From kloczek at zie.pg.gda.pl Thu Feb 2 21:45:15 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=) Date: Thu, 02 Feb 2006 22:45:15 +0100 Subject: rawhide report: 20060202 changes In-Reply-To: <1138915939.15099.34.camel@kloczek01.pracownicy.zie> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> <1138896089.15099.6.camel@kloczek01.pracownicy.zie> <20060202172433.2a79d274@python2> <20060202164652.GA5019@devserv.devel.redhat.com> <1138915939.15099.34.camel@kloczek01.pracownicy.zie> Message-ID: <1138916715.15099.41.camel@kloczek01.pracownicy.zie> Dnia 02-02-2006, czw o godzinie 22:32 +0100, Tomasz K?oczko napisa?(a): [..] > So .. question is: what is the logic is in include m17n to > distribution ? Im just use grep for find where m17n was used. interesting .. seems nowhere :-| $ grep m17n * | grep devel iiimf.spec:Buildrequires: gettext-devel %{?_with_freewnn_le: FreeWnn-devel, flex} %{?_with_m17n_le: m17n-lib-devel} iiimf.spec: - add buildrequires m17n-lib-devel iiimf is builded with m17n support by default disabled. kloczek From katzj at redhat.com Thu Feb 2 21:51:30 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 02 Feb 2006 16:51:30 -0500 Subject: Question about Fedora Extras 5 In-Reply-To: <43E20B87.1000300@karan.org> References: <43E133DA.8040605@freemail.hu> <20060202115112.78e641de@python2> <43E1E55C.8070806@fedoraproject.org> <20060202120532.7ad09981@python2> <43E1E956.9020202@fedoraproject.org> <20060202122824.05b702d3@python2> <6280325c0602020337p41a0ed71g9490130f3e495aeb@mail.gmail.com> <43E1F08D.6080104@fedoraproject.org> <6280325c0602020442t62b64510x8d84be66b9d174d5@mail.gmail.com> <43E20041.9030408@fedoraproject.org> <6280325c0602020509n1c88d59cn999437cc966c5a4a@mail.gmail.com> <43E20B87.1000300@karan.org> Message-ID: <1138917091.3451.10.camel@bree.local.net> On Thu, 2006-02-02 at 13:39 +0000, Karanbir Singh wrote: > n0dalus wrote: > > Atleast how I would imagine it is: The installer would ask you to > > provide any additional CDs if you need to at the end of the install, > > and would update any available packages from the CDs, whether they be > > extras or core or third party. > the ideal situation would be if the installer could ask 'before' the > install if you have any other Cd's around. And just install the updated > packages in the first place. Rather than needing to install the 'usual > stuff' and then having to run an update. > > and I believe some work is being done along these lines already. Yes, hopefully we'll be able to start doing this sort of stuff in the FC6 timeframe Jeremy From notting at redhat.com Thu Feb 2 21:50:45 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 2 Feb 2006 16:50:45 -0500 Subject: rawhide report: 20060202 changes In-Reply-To: <1138915939.15099.34.camel@kloczek01.pracownicy.zie> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> <1138896089.15099.6.camel@kloczek01.pracownicy.zie> <20060202172433.2a79d274@python2> <20060202164652.GA5019@devserv.devel.redhat.com> <1138915939.15099.34.camel@kloczek01.pracownicy.zie> Message-ID: <20060202215045.GA28604@devserv.devel.redhat.com> Tomasz K?oczko (kloczek at zie.pg.gda.pl) said: > Dnia 02-02-2006, czw o godzinie 11:46 -0500, Bill Nottingham napisa?(a): > [..] > > I expect it's not covered in comps right either - Jens, what's the > > logic behind this? > > (I'm just after short review of m17n) > IMO it will be better ask why m17n was included to distribution packages > list. Dependency of scim-m17n, replacement for scim-tables. Bill From katzj at redhat.com Thu Feb 2 21:53:15 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 02 Feb 2006 16:53:15 -0500 Subject: Question about Fedora Extras 5 In-Reply-To: <43E1E956.9020202@fedoraproject.org> References: <43E133DA.8040605@freemail.hu> <20060202115112.78e641de@python2> <43E1E55C.8070806@fedoraproject.org> <20060202120532.7ad09981@python2> <43E1E956.9020202@fedoraproject.org> Message-ID: <1138917196.3451.13.camel@bree.local.net> On Thu, 2006-02-02 at 16:43 +0530, Rahul Sundaram wrote: > So is this process documented? Can it be automated so a Extras ISO > image is created every few weeks or so for example?. During the Fedora > development process many of the packages in Extras seem to remain broken > for a longer time than the ones in core which led to the impression for > me that a release would be required to ensure that the packages work as > expected. The "what's required" will be changing with the movement to using yum as a backend for everything. Paul has been working on getting the CD support that we use in anaconda plumbed into yum proper as opposed to just in anaconda -- once that's done, it starts to be possible to add the support for CDs in pirut. Unfortunately, with the time constraints we're under, I'm not sure if we're really going to make it all the way to the finish line in time for FC5 :-/ Jeremy From katzj at redhat.com Thu Feb 2 21:58:14 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 02 Feb 2006 16:58:14 -0500 Subject: anaconda request - retry on network download failure In-Reply-To: References: Message-ID: <1138917494.3451.17.camel@bree.local.net> On Thu, 2006-02-02 at 13:37 -0500, Neal Becker wrote: > When using network installation, it SURE would be nice if anaconda gave a > choice to retry a failed package download! It should already be possible... if not, that's a bug (although before even asking, it should be trying a few times Jeremy From fedora at adslpipe.co.uk Thu Feb 2 22:08:23 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Thu, 02 Feb 2006 22:08:23 +0000 Subject: /usr/bin/gcj-dbtool problem In-Reply-To: <1138872156.7984.28.camel@xpc.home.erwinrol.com> References: <1138852508.7984.23.camel@xpc.home.erwinrol.com><20060202041120.GA794@redhat.com><1138857086.18976.7.camel@localhost.localdomain> <1138872156.7984.28.camel@xpc.home.erwinrol.com> Message-ID: <43E282D7.7010402@adslpipe.co.uk> Erwin Rol wrote: > But a deadlock might be the cause, because when i hang strace on the > program it seems to wait on a futex. I practically had to leave while true; do sleep 1; killall gcj-dbtool; done running while yum updating today with all the ant related updates ok, that allows yum to finish, but what damage am I doing to my class mappings in the meantime? is there a simple way to rebuild all these when the root cause gets nailed? From kloczek at zie.pg.gda.pl Thu Feb 2 22:23:59 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=) Date: Thu, 02 Feb 2006 23:23:59 +0100 Subject: rawhide report: 20060202 changes In-Reply-To: <20060202215045.GA28604@devserv.devel.redhat.com> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> <1138896089.15099.6.camel@kloczek01.pracownicy.zie> <20060202172433.2a79d274@python2> <20060202164652.GA5019@devserv.devel.redhat.com> <1138915939.15099.34.camel@kloczek01.pracownicy.zie> <20060202215045.GA28604@devserv.devel.redhat.com> Message-ID: <1138919039.25983.3.camel@kloczek01.pracownicy.zie> Dnia 02-02-2006, czw o godzinie 16:50 -0500, Bill Nottingham napisa?(a): > Tomasz K?oczko (kloczek at zie.pg.gda.pl) said: > > Dnia 02-02-2006, czw o godzinie 11:46 -0500, Bill Nottingham napisa?(a): > > [..] > > > I expect it's not covered in comps right either - Jens, what's the > > > logic behind this? > > > > (I'm just after short review of m17n) > > IMO it will be better ask why m17n was included to distribution packages > > list. > > Dependency of scim-m17n, replacement for scim-tables. Replacement ? I don't see Obsoletes rules beetween scim-m17n and scim-tables and/or why scim-tables is still around ? kloczek From notting at redhat.com Thu Feb 2 22:29:26 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 2 Feb 2006 17:29:26 -0500 Subject: rawhide report: 20060202 changes In-Reply-To: <1138919039.25983.3.camel@kloczek01.pracownicy.zie> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> <1138896089.15099.6.camel@kloczek01.pracownicy.zie> <20060202172433.2a79d274@python2> <20060202164652.GA5019@devserv.devel.redhat.com> <1138915939.15099.34.camel@kloczek01.pracownicy.zie> <20060202215045.GA28604@devserv.devel.redhat.com> <1138919039.25983.3.camel@kloczek01.pracownicy.zie> Message-ID: <20060202222925.GB4172@devserv.devel.redhat.com> Tomasz K?oczko (kloczek at zie.pg.gda.pl) said: > Dnia 02-02-2006, czw o godzinie 16:50 -0500, Bill Nottingham > napisa?(a): > > Tomasz K?oczko (kloczek at zie.pg.gda.pl) said: > > > Dnia 02-02-2006, czw o godzinie 11:46 -0500, Bill Nottingham napisa?(a): > > > [..] > > > > I expect it's not covered in comps right either - Jens, what's the > > > > logic behind this? > > > > > > (I'm just after short review of m17n) > > > IMO it will be better ask why m17n was included to distribution packages > > > list. > > > > Dependency of scim-m17n, replacement for scim-tables. > > Replacement ? > I don't see Obsoletes rules beetween scim-m17n and scim-tables and/or > why scim-tables is still around ? Sorry, replacement for some set of languages that scim-tables supported; I don't recall which ones. Bill From kloczek at zie.pg.gda.pl Thu Feb 2 22:52:02 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=) Date: Thu, 02 Feb 2006 23:52:02 +0100 Subject: rawhide report: 20060202 changes In-Reply-To: <20060202222925.GB4172@devserv.devel.redhat.com> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> <1138896089.15099.6.camel@kloczek01.pracownicy.zie> <20060202172433.2a79d274@python2> <20060202164652.GA5019@devserv.devel.redhat.com> <1138915939.15099.34.camel@kloczek01.pracownicy.zie> <20060202215045.GA28604@devserv.devel.redhat.com> <1138919039.25983.3.camel@kloczek01.pracownicy.zie> <20060202222925.GB4172@devserv.devel.redhat.com> Message-ID: <1138920722.25983.9.camel@kloczek01.pracownicy.zie> Dnia 02-02-2006, czw o godzinie 17:29 -0500, Bill Nottingham napisa?(a): [..] > > > Dependency of scim-m17n, replacement for scim-tables. > > > > Replacement ? > > I don't see Obsoletes rules beetween scim-m17n and scim-tables and/or > > why scim-tables is still around ? > > Sorry, replacement for some set of languages that scim-tables supported; > I don't recall which ones. So why m17n-db not supports *only* that scim-tables not supported languages ? Using m17n-lib without m17n-db do not have sense so packaging this in separated binary package also (IMO) do not have sense. kloczek From toshio at tiki-lounge.com Fri Feb 3 00:34:33 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 02 Feb 2006 16:34:33 -0800 Subject: AC_PATH_XTRA vs modular xorg In-Reply-To: <1138645189.3384.11.camel@localhost> References: <1138641747.3384.7.camel@localhost> <1138644376.5149.63.camel@mccallum.corsepiu.local> <1138645189.3384.11.camel@localhost> Message-ID: <1138926874.3411.57.camel@localhost> On Mon, 2006-01-30 at 10:19 -0800, Toshio Kuratomi wrote: > On Mon, 2006-01-30 at 19:06 +0100, Ralf Corsepius wrote: > > On Mon, 2006-01-30 at 09:22 -0800, Toshio Kuratomi wrote: > > > Does AC_PATH_XTRA (an autoconf macro used in configure.ac to figure out > > > X library and include paths) cause problems with modular xorg? > > Nope, it doesn't, at least it should not. > > > Thanks -- I'll take a harder look at what exactly is broken in this > configure script. > The problem turns out to be autoconf's AC_PATH_X macro's checking for the existence of X11/Intrinsic.h which is owned by libXt-devel. This isn't a needed dependency for building the package and has been patched upstream but is not yet in our autoconf. Orion opened a bug on this earlier: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176379 -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From michael at knox.net.nz Fri Feb 3 00:08:57 2006 From: michael at knox.net.nz (Michael J Knox) Date: Fri, 03 Feb 2006 13:08:57 +1300 Subject: e1000 in rawhide kernel Message-ID: <1138925360.3728.5.camel@nemausa.et.endace.com> Hi all, I am looking at a problem with the e1000 driver in rawhide (will the installed FC5t2 kernel). I have a 82573E onboard NIC that refuses to obtain a DHCP IP. If its statically asigned, I am ok. lspic output: 03:00.0 Ethernet Controller: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (rev 0.3) The e1000 kernel module is loaded, ifconfig shows that eth0 was brought up. dmesg shows: e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection e1000: eth0: e1000_watchdog_task: NIC Link is up 100Mbps Full Duplex. Has anyone else seen this issue? Thanks Michael From davej at redhat.com Fri Feb 3 01:34:45 2006 From: davej at redhat.com (Dave Jones) Date: Thu, 2 Feb 2006 20:34:45 -0500 Subject: e1000 in rawhide kernel In-Reply-To: <1138925360.3728.5.camel@nemausa.et.endace.com> References: <1138925360.3728.5.camel@nemausa.et.endace.com> Message-ID: <20060203013445.GB10209@redhat.com> On Fri, Feb 03, 2006 at 01:08:57PM +1300, Michael J Knox wrote: > Hi all, > > I am looking at a problem with the e1000 driver in rawhide (will the > installed FC5t2 kernel). > > I have a 82573E onboard NIC that refuses to obtain a DHCP IP. If its > statically asigned, I am ok. > > lspic output: > > 03:00.0 Ethernet Controller: Intel Corporation 82573E Gigabit Ethernet > Controller (Copper) (rev 0.3) > > The e1000 kernel module is loaded, ifconfig shows that eth0 was brought > up. > > dmesg shows: > > e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection > e1000: eth0: e1000_watchdog_task: NIC Link is up 100Mbps Full Duplex. There have been a ton of e1000 changes since the test2 kernel, please try and reproduce with the latest rawhide kernel, and if it's still a problem, file a bug in bugzilla. Dave From michael at knox.net.nz Fri Feb 3 02:12:22 2006 From: michael at knox.net.nz (Michael J Knox) Date: Fri, 03 Feb 2006 15:12:22 +1300 Subject: e1000 in rawhide kernel In-Reply-To: <20060203013445.GB10209@redhat.com> References: <1138925360.3728.5.camel@nemausa.et.endace.com> <20060203013445.GB10209@redhat.com> Message-ID: <1138932766.3728.19.camel@nemausa.et.endace.com> On Thu, 2006-02-02 at 20:34 -0500, Dave Jones wrote: > On Fri, Feb 03, 2006 at 01:08:57PM +1300, Michael J Knox wrote: > > Hi all, > > > > I am looking at a problem with the e1000 driver in rawhide (will the > > installed FC5t2 kernel). > > > > I have a 82573E onboard NIC that refuses to obtain a DHCP IP. If its > > statically asigned, I am ok. > > > > lspic output: > > > > 03:00.0 Ethernet Controller: Intel Corporation 82573E Gigabit Ethernet > > Controller (Copper) (rev 0.3) > > > > The e1000 kernel module is loaded, ifconfig shows that eth0 was brought > > up. > > > > dmesg shows: > > > > e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection > > e1000: eth0: e1000_watchdog_task: NIC Link is up 100Mbps Full Duplex. > > There have been a ton of e1000 changes since the test2 kernel, > please try and reproduce with the latest rawhide kernel, and if it's > still a problem, file a bug in bugzilla. > > Dave > Ok, tried that, no change. Bug report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179805 One interesting note, the current rawhide kernel (2.6.15-1.1884_FC5) broke e100, so I am filing a bug for that too. Michael From louisg00 at bellsouth.net Fri Feb 3 02:22:55 2006 From: louisg00 at bellsouth.net (louisg00 at bellsouth.net) Date: Thu, 2 Feb 2006 21:22:55 -0500 Subject: Booting problems with kernel and selinux Message-ID: <20060203022255.DKVU23047.ibm69aec.bellsouth.net@mail.bellsouth.net> > > louisg00 at bellsouth.net wrote: > > > > Just installed rawhide yesterday and noticed a kernel panic when in selinux enforcing mode. I > > appended selinux=0 and it booted right up. Todays kernel (1884) did not panic but got stuck on > > starting udev. Again rebooted with selinux=0 and was fine. > > > > -Louis > dwalsh at redhat.com wrote: > > Instead of booting with selinux=0, boot with enforcing=0 and report the AVC messages. You might > need to relabel. > > touch /.autorelabel > reboot I did a relabel but still having problems. This is what I get: First I get many lines of this: Feb 2 20:53:29 soncomputer kernel: inode_doinit_with_dentry: context_to_sid(unlabeled) returned 22 for dev=hda3 ino=724920 with different ino #, Then this: Feb 2 20:53:29 soncomputer kernel: audit(1138931589.627:32): avc: denied { search } for pid=2095 comm="avahi-daemon" name="/" dev=hda3 ino=2 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=dir Feb 2 20:53:30 soncomputer kernel: audit(1138931589.627:33): avc: denied { search } for pid=2095 comm="avahi-daemon" name="etc" dev=hda3 ino=650881 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir Feb 2 20:53:30 soncomputer kernel: inode_doinit_with_dentry: context_to_sid(unlabeled) returned 22 for dev=hda3 ino=532524 Feb 2 20:53:30 soncomputer kernel: audit(1138931589.639:34): avc: denied { read } for pid=2095 comm="avahi-daemon" name="libdaemon.so.0" dev=hda3 ino=532524 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=lnk_file Feb 2 20:53:30 soncomputer kernel: audit(1138931589.639:35): avc: denied { read } for pid=2095 comm="avahi-daemon" name="libdaemon.so.0.2.4" dev=hda3 ino=551684 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file Feb 2 20:53:30 soncomputer kernel: audit(1138931589.651:36): avc: denied { getattr } for pid=2095 comm="avahi-daemon" name="libdaemon.so.0.2.4" dev=hda3 ino=551684 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file Feb 2 20:53:30 soncomputer kernel: audit(1138931589.651:37): avc: denied { execute } for pid=2095 comm="avahi-daemon" name="libdaemon.so.0.2.4" dev=hda3 ino=551684 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file Feb 2 20:53:30 soncomputer kernel: audit(1138931589.651:38): avc: denied { read } for pid=2095 comm="avahi-daemon" name="libexpat.so.0" dev=hda3 ino=1627271 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=lnk_file Feb 2 20:53:30 soncomputer kernel: audit(1138931589.671:39): avc: denied { read } for pid=2097 comm="avahi-daemon" name="nsswitch.conf" dev=hda3 ino=650928 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file Feb 2 20:53:30 soncomputer kernel: audit(1138931589.671:40): avc: denied { getattr } for pid=2097 comm="avahi-daemon" name="nsswitch.conf" dev=hda3 ino=650928 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file Feb 2 20:53:30 soncomputer kernel: audit(1138931589.671:41): avc: denied { execute } for pid=2097 comm="avahi-daemon" name="libnss_files-2.3.90.so" dev=hda3 ino=1627241 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file Feb 2 20:53:30 soncomputer kernel: audit(1138931589.671:42): avc: denied { write } for pid=2097 comm="avahi-daemon" name="log" dev=tmpfs ino=4859 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=sock_file Feb 2 20:53:30 soncomputer kernel: audit(1138931589.671:43): avc: denied { sendto } for pid=2097 comm="avahi-daemon" name="log" scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_dgram_socket And back to this Feb 2 20:53:30 soncomputer kernel: inode_doinit_with_dentry: context_to_sid(unlabeled) returned 22 for dev=hda3 ino=1112204 going down the log: Feb 2 20:53:35 soncomputer kernel: audit(1138931592.367:44): avc: denied { write } for pid=2097 comm="avahi-daemon" name="system_bus_socket" dev=hda3 ino=1823236 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=sock_file Feb 2 20:53:35 soncomputer kernel: audit(1138931592.367:45): avc: denied { connectto } for pid=2097 comm="avahi-daemon" name="system_bus_socket" scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket Feb 2 20:53:35 soncomputer kernel: audit(1138931592.367:46): user pid=1843 uid=81 auid=4294967295 msg='avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.DBus member=Hello dest=org.freedesktop.DBus spid=2097 scontext=system_u:system_r:avahi_t tcontext=system_u:system_r:initrc_t tclass=dbus Feb 2 20:53:35 soncomputer kernel: : exe="?" (sauid=81, hostname=?, addr=?, terminal=?)' Feb 2 20:53:35 soncomputer kernel: audit(1138931592.371:47): user pid=1843 uid=81 auid=4294967295 msg='avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.DBus member=RequestName dest=org.freedesktop.DBus spid=2097 scontext=system_u:system_r:avahi_t tcontext=system_u:system_r:initrc_t tclass=dbus Feb 2 20:53:35 soncomputer kernel: : exe="?" (sauid=81, hostname=?, addr=?, terminal=?)' Feb 2 20:53:35 soncomputer kernel: audit(1138931592.371:48): user pid=1843 uid=81 auid=4294967295 msg='avc: denied { acquire_svc } for service=org.freedesktop.Avahi spid=2097 scontext=system_u:system_r:avahi_t tcontext=system_u:system_r:initrc_t tclass=dbus Feb 2 20:53:35 soncomputer kernel: : exe="?" (sauid=81, hostname=?, addr=?, terminal=?)' Feb 2 20:53:35 soncomputer kernel: audit(1138931592.375:49): user pid=1843 uid=81 auid=4294967295 msg='avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.DBus member=AddMatch dest=org.freedesktop.DBus spid=2097 scontext=system_u:system_r:avahi_t tcontext=system_u:system_r:initrc_t tclass=dbus Feb 2 20:53:35 soncomputer kernel: : exe="?" (sauid=81, hostname=?, addr=?, terminal=?)' ............. Feb 2 20:53:35 soncomputer kernel: input: PC Speaker as /class/input/input2 Feb 2 20:53:35 soncomputer kernel: audit(1138931598.736:50): avc: denied { search } for pid=2232 comm="consoletype" name="/" dev=hda3 ino=2 scontext=system_u:system_r:consoletype_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=dir Feb 2 20:53:35 soncomputer kernel: audit(1138931598.736:51): avc: denied { search } for pid=2232 comm="consoletype" name="etc" dev=hda3 ino=650881 scontext=system_u:system_r:consoletype_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir Feb 2 20:53:35 soncomputer kernel: audit(1138931598.736:52): avc: denied { read } for pid=2232 comm="consoletype" name="libc.so.6" dev=hda3 ino=1627226 scontext=system_u:system_r:consoletype_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=lnk_file Feb 2 20:53:35 soncomputer kernel: audit(1138931598.736:53): avc: denied { read } for pid=2232 comm="consoletype" name="libc-2.3.90.so" dev=hda3 ino=1629605 scontext=system_u:system_r:consoletype_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file Feb 2 20:53:35 soncomputer kernel: audit(1138931598.736:54): avc: denied { getattr } for pid=2232 comm="consoletype" name="libc-2.3.90.so" dev=hda3 ino=1629605 scontext=system_u:system_r:consoletype_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file Feb 2 20:53:35 soncomputer kernel: audit(1138931598.736:55): avc: denied { execute } for pid=2232 comm="consoletype" name="libc-2.3.90.so" dev=hda3 ino=1629605 scontext=system_u:system_r:consoletype_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file .............. Feb 2 20:53:53 soncomputer kernel: audit(1138931631.126:57): avc: denied { search } for pid=2472 comm="automount" name="/" dev=hda3 ino=2 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=dir .............. Feb 2 20:54:17 soncomputer kernel: audit(1138931657.503:58): avc: denied { associate } for pid=2501 comm="su" name=".xauthMKz24i" scontext=user_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem From petersen at redhat.com Fri Feb 3 03:26:30 2006 From: petersen at redhat.com (Jens Petersen) Date: Fri, 3 Feb 2006 12:26:30 +0900 Subject: rawhide report: 20060202 changes In-Reply-To: <1138896089.15099.6.camel@kloczek01.pracownicy.zie> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> <1138896089.15099.6.camel@kloczek01.pracownicy.zie> Message-ID: <20060203122630.a157a068.petersen@redhat.com> On Thu, 02 Feb 2006 17:01:29 +0100 Tomasz K?oczko wrote: > Instead [of] generat[ing] 41 binary subpackages m17n-db* each with support > for one language better [to] generate one with correctly used %lang() > macros in %files list. The problem is that most people using m17n only need one or two of its langs installed at most, but not necessarily the ones for which they want software translations say (and anyway by default all translations are installed by default nowadays afaict). If all the input maps in m17n-db get installed by default, then about 40 languages appear in the SCIM language selection menu suddenly which is not nice. Eg I run a Japanese desktop, but also want to be able to input European languages with m17n-db-latin say: how can I do that without pulling in all the other langs under your packaging? Jens From petersen at redhat.com Fri Feb 3 03:36:27 2006 From: petersen at redhat.com (Jens Petersen) Date: Fri, 3 Feb 2006 12:36:27 +0900 Subject: rawhide report: 20060202 changes In-Reply-To: <20060202164652.GA5019@devserv.devel.redhat.com> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> <1138896089.15099.6.camel@kloczek01.pracownicy.zie> <20060202172433.2a79d274@python2> <20060202164652.GA5019@devserv.devel.redhat.com> Message-ID: <20060203123627.15f9ce5f.petersen@redhat.com> On Thu, 2 Feb 2006 11:46:52 -0500 Bill Nottingham wrote: > Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > > I'm not sure I understood everything perfectly, but I'd have to agree > > about the less-than-optimal splitting, as AFAICS most of those language > > packages are 8kB big... It is not an question of size here, it is a question of being able to select the languages for which input maps get installed for m17n-db. Eventually we thinking now to have a scheme to allow the selection what input methods get enabled when an input method gets installed under SCIM, but until that is available I believe the current packaging is the best that can be done. > I expect it's not covered in comps right either - Jens, what's the > logic behind this? Right various languages should probably be added to comps: this will certainly happen for Indian scripts at least which I'm currently working on. On the other hand of course not every language needs to be comps either: I don't think most Swedes say need to have m17n-db-swedish installed for example. Jens From davej at redhat.com Fri Feb 3 03:47:18 2006 From: davej at redhat.com (Dave Jones) Date: Thu, 2 Feb 2006 22:47:18 -0500 Subject: e1000 in rawhide kernel In-Reply-To: <1138932766.3728.19.camel@nemausa.et.endace.com> References: <1138925360.3728.5.camel@nemausa.et.endace.com> <20060203013445.GB10209@redhat.com> <1138932766.3728.19.camel@nemausa.et.endace.com> Message-ID: <20060203034718.GE10209@redhat.com> On Fri, Feb 03, 2006 at 03:12:22PM +1300, Michael J Knox wrote: > On Thu, 2006-02-02 at 20:34 -0500, Dave Jones wrote: > > On Fri, Feb 03, 2006 at 01:08:57PM +1300, Michael J Knox wrote: > > > Hi all, > > > > > > I am looking at a problem with the e1000 driver in rawhide (will the > > > installed FC5t2 kernel). > > > > > > I have a 82573E onboard NIC that refuses to obtain a DHCP IP. If its > > > statically asigned, I am ok. > > > > > > lspic output: > > > > > > 03:00.0 Ethernet Controller: Intel Corporation 82573E Gigabit Ethernet > > > Controller (Copper) (rev 0.3) > > > > > > The e1000 kernel module is loaded, ifconfig shows that eth0 was brought > > > up. > > > > > > dmesg shows: > > > > > > e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection > > > e1000: eth0: e1000_watchdog_task: NIC Link is up 100Mbps Full Duplex. > > > > There have been a ton of e1000 changes since the test2 kernel, > > please try and reproduce with the latest rawhide kernel, and if it's > > still a problem, file a bug in bugzilla. > > > > Dave > > > > Ok, tried that, no change. > > Bug report: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179805 > > One interesting note, the current rawhide kernel (2.6.15-1.1884_FC5) > broke e100, so I am filing a bug for that too. kernel-2.6.15-1.1895_FC5 is todays kernel. I guess yum picked up a stale mirror ? There's also an even higher rev which will be tomorrows build at http://people.redhat.com/davej/kernels/Fedora/devel/ Dave From louisg00 at bellsouth.net Fri Feb 3 02:22:55 2006 From: louisg00 at bellsouth.net (louisg00 at bellsouth.net) Date: Thu, 2 Feb 2006 21:22:55 -0500 Subject: Booting problems with kernel and selinux Message-ID: <20060203022255.DKVU23047.ibm69aec.bellsouth.net@mail.bellsouth.net> > > louisg00 at bellsouth.net wrote: > > > > Just installed rawhide yesterday and noticed a kernel panic when in selinux enforcing mode. I > > appended selinux=0 and it booted right up. Todays kernel (1884) did not panic but got stuck on > > starting udev. Again rebooted with selinux=0 and was fine. > > > > -Louis > dwalsh at redhat.com wrote: > > Instead of booting with selinux=0, boot with enforcing=0 and report the AVC messages. You might > need to relabel. > > touch /.autorelabel > reboot I did a relabel but still having problems. This is what I get: First I get many lines of this: Feb 2 20:53:29 soncomputer kernel: inode_doinit_with_dentry: context_to_sid(unlabeled) returned 22 for dev=hda3 ino=724920 with different ino #, Then this: Feb 2 20:53:29 soncomputer kernel: audit(1138931589.627:32): avc: denied { search } for pid=2095 comm="avahi-daemon" name="/" dev=hda3 ino=2 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=dir Feb 2 20:53:30 soncomputer kernel: audit(1138931589.627:33): avc: denied { search } for pid=2095 comm="avahi-daemon" name="etc" dev=hda3 ino=650881 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir Feb 2 20:53:30 soncomputer kernel: inode_doinit_with_dentry: context_to_sid(unlabeled) returned 22 for dev=hda3 ino=532524 Feb 2 20:53:30 soncomputer kernel: audit(1138931589.639:34): avc: denied { read } for pid=2095 comm="avahi-daemon" name="libdaemon.so.0" dev=hda3 ino=532524 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=lnk_file Feb 2 20:53:30 soncomputer kernel: audit(1138931589.639:35): avc: denied { read } for pid=2095 comm="avahi-daemon" name="libdaemon.so.0.2.4" dev=hda3 ino=551684 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file Feb 2 20:53:30 soncomputer kernel: audit(1138931589.651:36): avc: denied { getattr } for pid=2095 comm="avahi-daemon" name="libdaemon.so.0.2.4" dev=hda3 ino=551684 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file Feb 2 20:53:30 soncomputer kernel: audit(1138931589.651:37): avc: denied { execute } for pid=2095 comm="avahi-daemon" name="libdaemon.so.0.2.4" dev=hda3 ino=551684 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file Feb 2 20:53:30 soncomputer kernel: audit(1138931589.651:38): avc: denied { read } for pid=2095 comm="avahi-daemon" name="libexpat.so.0" dev=hda3 ino=1627271 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=lnk_file Feb 2 20:53:30 soncomputer kernel: audit(1138931589.671:39): avc: denied { read } for pid=2097 comm="avahi-daemon" name="nsswitch.conf" dev=hda3 ino=650928 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file Feb 2 20:53:30 soncomputer kernel: audit(1138931589.671:40): avc: denied { getattr } for pid=2097 comm="avahi-daemon" name="nsswitch.conf" dev=hda3 ino=650928 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file Feb 2 20:53:30 soncomputer kernel: audit(1138931589.671:41): avc: denied { execute } for pid=2097 comm="avahi-daemon" name="libnss_files-2.3.90.so" dev=hda3 ino=1627241 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file Feb 2 20:53:30 soncomputer kernel: audit(1138931589.671:42): avc: denied { write } for pid=2097 comm="avahi-daemon" name="log" dev=tmpfs ino=4859 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=sock_file Feb 2 20:53:30 soncomputer kernel: audit(1138931589.671:43): avc: denied { sendto } for pid=2097 comm="avahi-daemon" name="log" scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_dgram_socket And back to this Feb 2 20:53:30 soncomputer kernel: inode_doinit_with_dentry: context_to_sid(unlabeled) returned 22 for dev=hda3 ino=1112204 going down the log: Feb 2 20:53:35 soncomputer kernel: audit(1138931592.367:44): avc: denied { write } for pid=2097 comm="avahi-daemon" name="system_bus_socket" dev=hda3 ino=1823236 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=sock_file Feb 2 20:53:35 soncomputer kernel: audit(1138931592.367:45): avc: denied { connectto } for pid=2097 comm="avahi-daemon" name="system_bus_socket" scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket Feb 2 20:53:35 soncomputer kernel: audit(1138931592.367:46): user pid=1843 uid=81 auid=4294967295 msg='avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.DBus member=Hello dest=org.freedesktop.DBus spid=2097 scontext=system_u:system_r:avahi_t tcontext=system_u:system_r:initrc_t tclass=dbus Feb 2 20:53:35 soncomputer kernel: : exe="?" (sauid=81, hostname=?, addr=?, terminal=?)' Feb 2 20:53:35 soncomputer kernel: audit(1138931592.371:47): user pid=1843 uid=81 auid=4294967295 msg='avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.DBus member=RequestName dest=org.freedesktop.DBus spid=2097 scontext=system_u:system_r:avahi_t tcontext=system_u:system_r:initrc_t tclass=dbus Feb 2 20:53:35 soncomputer kernel: : exe="?" (sauid=81, hostname=?, addr=?, terminal=?)' Feb 2 20:53:35 soncomputer kernel: audit(1138931592.371:48): user pid=1843 uid=81 auid=4294967295 msg='avc: denied { acquire_svc } for service=org.freedesktop.Avahi spid=2097 scontext=system_u:system_r:avahi_t tcontext=system_u:system_r:initrc_t tclass=dbus Feb 2 20:53:35 soncomputer kernel: : exe="?" (sauid=81, hostname=?, addr=?, terminal=?)' Feb 2 20:53:35 soncomputer kernel: audit(1138931592.375:49): user pid=1843 uid=81 auid=4294967295 msg='avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.DBus member=AddMatch dest=org.freedesktop.DBus spid=2097 scontext=system_u:system_r:avahi_t tcontext=system_u:system_r:initrc_t tclass=dbus Feb 2 20:53:35 soncomputer kernel: : exe="?" (sauid=81, hostname=?, addr=?, terminal=?)' ............. Feb 2 20:53:35 soncomputer kernel: input: PC Speaker as /class/input/input2 Feb 2 20:53:35 soncomputer kernel: audit(1138931598.736:50): avc: denied { search } for pid=2232 comm="consoletype" name="/" dev=hda3 ino=2 scontext=system_u:system_r:consoletype_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=dir Feb 2 20:53:35 soncomputer kernel: audit(1138931598.736:51): avc: denied { search } for pid=2232 comm="consoletype" name="etc" dev=hda3 ino=650881 scontext=system_u:system_r:consoletype_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir Feb 2 20:53:35 soncomputer kernel: audit(1138931598.736:52): avc: denied { read } for pid=2232 comm="consoletype" name="libc.so.6" dev=hda3 ino=1627226 scontext=system_u:system_r:consoletype_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=lnk_file Feb 2 20:53:35 soncomputer kernel: audit(1138931598.736:53): avc: denied { read } for pid=2232 comm="consoletype" name="libc-2.3.90.so" dev=hda3 ino=1629605 scontext=system_u:system_r:consoletype_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file Feb 2 20:53:35 soncomputer kernel: audit(1138931598.736:54): avc: denied { getattr } for pid=2232 comm="consoletype" name="libc-2.3.90.so" dev=hda3 ino=1629605 scontext=system_u:system_r:consoletype_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file Feb 2 20:53:35 soncomputer kernel: audit(1138931598.736:55): avc: denied { execute } for pid=2232 comm="consoletype" name="libc-2.3.90.so" dev=hda3 ino=1629605 scontext=system_u:system_r:consoletype_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file .............. Feb 2 20:53:53 soncomputer kernel: audit(1138931631.126:57): avc: denied { search } for pid=2472 comm="automount" name="/" dev=hda3 ino=2 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=dir .............. Feb 2 20:54:17 soncomputer kernel: audit(1138931657.503:58): avc: denied { associate } for pid=2501 comm="su" name=".xauthMKz24i" scontext=user_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem From michael at knox.net.nz Fri Feb 3 03:51:28 2006 From: michael at knox.net.nz (Michael J Knox) Date: Fri, 03 Feb 2006 16:51:28 +1300 Subject: e1000 in rawhide kernel In-Reply-To: <20060203034718.GE10209@redhat.com> References: <1138925360.3728.5.camel@nemausa.et.endace.com> <20060203013445.GB10209@redhat.com> <1138932766.3728.19.camel@nemausa.et.endace.com> <20060203034718.GE10209@redhat.com> Message-ID: <1138938689.21901.1.camel@pingu.homenetwork.lan> On Thu, 2006-02-02 at 22:47 -0500, Dave Jones wrote: > On Fri, Feb 03, 2006 at 03:12:22PM +1300, Michael J Knox wrote: > > On Thu, 2006-02-02 at 20:34 -0500, Dave Jones wrote: > > > On Fri, Feb 03, 2006 at 01:08:57PM +1300, Michael J Knox wrote: > > > > Hi all, > > > > > > > > I am looking at a problem with the e1000 driver in rawhide (will the > > > > installed FC5t2 kernel). > > > > > > > > I have a 82573E onboard NIC that refuses to obtain a DHCP IP. If its > > > > statically asigned, I am ok. > > > > > > > > lspic output: > > > > > > > > 03:00.0 Ethernet Controller: Intel Corporation 82573E Gigabit Ethernet > > > > Controller (Copper) (rev 0.3) > > > > > > > > The e1000 kernel module is loaded, ifconfig shows that eth0 was brought > > > > up. > > > > > > > > dmesg shows: > > > > > > > > e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection > > > > e1000: eth0: e1000_watchdog_task: NIC Link is up 100Mbps Full Duplex. > > > > > > There have been a ton of e1000 changes since the test2 kernel, > > > please try and reproduce with the latest rawhide kernel, and if it's > > > still a problem, file a bug in bugzilla. > > > > > > Dave > > > > > > > Ok, tried that, no change. > > > > Bug report: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179805 > > > > One interesting note, the current rawhide kernel (2.6.15-1.1884_FC5) > > broke e100, so I am filing a bug for that too. > > kernel-2.6.15-1.1895_FC5 is todays kernel. > I guess yum picked up a stale mirror ? > There's also an even higher rev which will be tomorrows build > at http://people.redhat.com/davej/kernels/Fedora/devel/ > > Dave > > Yeah, I tired today's kernel too, I must have grabbed a stale mirror earlier. Same results on both accounts. I will go into work tomorrow and try the higher rev and see what happens I do have another machine, same motherboard running debian etch 2.6.12-2-686 (not by choice) using e1000 for the NIC. Not sure if that helps. Michael From petersen at redhat.com Fri Feb 3 04:00:49 2006 From: petersen at redhat.com (Jens Petersen) Date: Fri, 3 Feb 2006 13:00:49 +0900 Subject: rawhide report: 20060202 changes In-Reply-To: <1138915939.15099.34.camel@kloczek01.pracownicy.zie> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> <1138896089.15099.6.camel@kloczek01.pracownicy.zie> <20060202172433.2a79d274@python2> <20060202164652.GA5019@devserv.devel.redhat.com> <1138915939.15099.34.camel@kloczek01.pracownicy.zie> Message-ID: <20060203130049.b8de9fc7.petersen@redhat.com> On Thu, 02 Feb 2006 22:32:19 +0100 Tomasz K?oczko wrote: > On first look m17n it is real piece of crap. Why? Because in > current form it duplicates many things from libc locale database and few > more things (did I write "duplicates" ? .. correction: it is not second > copy of locale/encodings description because second sits in XLOCALE > [1]). That is basically why I separated some of the large datafiles to a separate subpackage (m17n-db-datafiles) so they don't need to be installed by default. The main m17n-db package manifest is only 86kB. > If it is realy neccassary for some importand new package better will be > invest more energy in (re)development this library for not bloating > distribution using (IMO) discussabe quality code :> Well duplication of information (while not desirable) doesn't imply poor quality per se. > So .. question is: what is the logic is in include m17n to > distribution ? m17n-db and m17n-lib were included in Fedora Core because m17n-db supports input tables for a lot of languages and it allows much more sophisticated input maps (eg stateful one) than scim-tables does: for example Indian Itrans tables can't be supported by scim-tables but they are by m17n. So the thinking is to use scim-tables for very large simple tables like for Chinese and use m17n for smaller complex scripts and languages, like Indian and European languages. And SCIM upstream supports this view too. Hope it makes a bit more sense now. m17n-lib supports a gui library and OpenType fonts (using libotf), but those have been disabled in the Fedora package. m17n-db.noarch just includes the minimal datafiles needed for scim-m17n to work with m17n-lib fwiw. Jens From petersen at redhat.com Fri Feb 3 04:09:27 2006 From: petersen at redhat.com (Jens Petersen) Date: Fri, 3 Feb 2006 13:09:27 +0900 Subject: rawhide report: 20060202 changes In-Reply-To: <20060202222925.GB4172@devserv.devel.redhat.com> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> <1138896089.15099.6.camel@kloczek01.pracownicy.zie> <20060202172433.2a79d274@python2> <20060202164652.GA5019@devserv.devel.redhat.com> <1138915939.15099.34.camel@kloczek01.pracownicy.zie> <20060202215045.GA28604@devserv.devel.redhat.com> <1138919039.25983.3.camel@kloczek01.pracownicy.zie> <20060202222925.GB4172@devserv.devel.redhat.com> Message-ID: <20060203130927.b4c6cd3c.petersen@redhat.com> On Thu, 2 Feb 2006 17:29:26 -0500 Bill Nottingham wrote: > Sorry, replacement for some set of languages that scim-tables supported; > I don't recall which ones. Primarily for Indian and European languages, since scim-tables is designed and optimised for large input tables of Chinese characters. From petersen at redhat.com Fri Feb 3 04:19:06 2006 From: petersen at redhat.com (Jens Petersen) Date: Fri, 3 Feb 2006 13:19:06 +0900 Subject: rawhide report: 20060202 changes In-Reply-To: <1138920722.25983.9.camel@kloczek01.pracownicy.zie> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> <1138896089.15099.6.camel@kloczek01.pracownicy.zie> <20060202172433.2a79d274@python2> <20060202164652.GA5019@devserv.devel.redhat.com> <1138915939.15099.34.camel@kloczek01.pracownicy.zie> <20060202215045.GA28604@devserv.devel.redhat.com> <1138919039.25983.3.camel@kloczek01.pracownicy.zie> <20060202222925.GB4172@devserv.devel.redhat.com> <1138920722.25983.9.camel@kloczek01.pracownicy.zie> Message-ID: <20060203131906.6f98678b.petersen@redhat.com> On Thu, 02 Feb 2006 23:52:02 +0100 Tomasz K?oczko wrote: > So why m17n-db not supports *only* that scim-tables not supported > languages ? Well in the ideal world yes, and I think will be the tendency in the long run: when I've finished porting the Indian tables in scim-tables to m17n-db, I think they can be removed from scim-tables: certainly I plan to do that for the Fedora package. > Using m17n-lib without m17n-db do not have sense so packaging this in > separated binary package also (IMO) do not have sense. Well it makes sense from the point of view of updates: it makes it possible to add some input maps to m17n-db or update the version without forcing people to have to update their m17n-lib packages for no reason, and vice versa. I don't see any advantage in merging the packages together. Jens From davej at redhat.com Fri Feb 3 04:28:07 2006 From: davej at redhat.com (Dave Jones) Date: Thu, 2 Feb 2006 23:28:07 -0500 Subject: e1000 in rawhide kernel In-Reply-To: <1138938689.21901.1.camel@pingu.homenetwork.lan> References: <1138925360.3728.5.camel@nemausa.et.endace.com> <20060203013445.GB10209@redhat.com> <1138932766.3728.19.camel@nemausa.et.endace.com> <20060203034718.GE10209@redhat.com> <1138938689.21901.1.camel@pingu.homenetwork.lan> Message-ID: <20060203042807.GI10209@redhat.com> On Fri, Feb 03, 2006 at 04:51:28PM +1300, Michael J Knox wrote: > Yeah, I tired today's kernel too, I must have grabbed a stale mirror > earlier. Same results on both accounts. > > I will go into work tomorrow and try the higher rev and see what happens > > I do have another machine, same motherboard running debian etch > 2.6.12-2-686 (not by choice) using e1000 for the NIC. Not sure if that > helps. Only for archaelogical reasons :) So much has changed since 2.6.12 that it's more or less irrelevant. Dave From fcd-cornette at insight.rr.com Fri Feb 3 04:47:58 2006 From: fcd-cornette at insight.rr.com (Jim Cornette) Date: Thu, 02 Feb 2006 23:47:58 -0500 Subject: Replace mozilla with SeaMonkey? In-Reply-To: <43E26DDD.5050202@redhat.com> References: <1138886357.499.17.camel@gilboa-work-dev> <43E25330.10901@redhat.com> <43E26DDD.5050202@redhat.com> Message-ID: <43E2E07E.7020501@insight.rr.com> Kai Engert wrote: > Yes, I already worked in my spare time on producing SeaMonkey RPM packages. > I selected a combination of patches from the set currently used in > Firefox, Thunderbird and Mozilla RPM packages. > I made it so that Mozilla and SeaMonkey can be installed at the same time. Would they use the same profile as Netscape 7 does? The query is mainly due to email accounts, bookmarks are rather large. I don't think needing to import all this information into another profile would be desirable. The different directories for Thunderbird and for mozilla are one feature that I do not care for. > > I would like to wait with publishing the package until Chris had a > chance to review spec file and patches. > I'll post to the list once we're done. > Also note, this will be my first package for Extras, so it might take me > a bit longer to get it included there. Looking forward to the rpms being available in Extras. Either location is fine with me. Since Seamonkey is a suite instead of seperate applications, I would appreciate its inclusion somewhere. > > For FC 5, we think Mozilla 1.7.x should still be included. > That seems reasonable as other packages might depend on Mozilla (?), and > the GRE it provides (see /etc/gre.conf). I don't know whether SeaMonkey > 1.0 can be used as a compatible drop-in replacement for that. It's > probably not a good idea to remove Mozilla that late in the FC 5 release > process. I agree. > > After FC 5, we might either remove Mozilla 1.7.x from Core, or move it > over to Extras. But if Extras contains SeaMonkey, there might no longer > be a need to provide Mozilla 1.7.x, too. Seamonkey maintenence sounds sufficient. I just like the composer for dealing with html docs in windows and Linux. I could do with just a drop in replacement that is being maintained. > > Kai > > Christopher Aillon wrote: > >> On 02/02/2006 08:19 AM, Gilboa Davara wrote: >> >>> Helllo all, >>> >>> With the release of the SeaMonkey 1.0, shouldn't Fedora replace the >>> aging mozilla-1.7.x package (.12 in both rawhide and FC5T2) with the new >>> SeaMonkey package? >>> http://www.mozilla.org/projects/seamonkey/ I downloaded the non-rpm version and will try out the package. >> >> >> The eventual goal is to drop the mozilla based browsers from Core and >> move them to Extras, so SeaMonkey should do that now. I think Kai >> Engert has an SRPM lying around somewhere. > > > Jim -- Where do you want Bill Gates to go today? -- From a Slashdot.org post From fcd-cornette at insight.rr.com Fri Feb 3 05:01:18 2006 From: fcd-cornette at insight.rr.com (Jim Cornette) Date: Fri, 03 Feb 2006 00:01:18 -0500 Subject: Replace mozilla with SeaMonkey? In-Reply-To: <1138886357.499.17.camel@gilboa-work-dev> References: <1138886357.499.17.camel@gilboa-work-dev> Message-ID: <43E2E39E.2050205@insight.rr.com> Gilboa Davara wrote: > Helllo all, > > With the release of the SeaMonkey 1.0, shouldn't Fedora replace the > aging mozilla-1.7.x package (.12 in both rawhide and FC5T2) with the new > SeaMonkey package? > http://www.mozilla.org/projects/seamonkey/ > > Gilboa > The responsiveness for Sea monkey over Mozilla seems excellent. The underlined spelling check of words is nice also. It is strange that mozilla or Seamonkey are not included in the dictionary though, microsoft is included, why not the product name also. Thanks for making the suggestion. Jim -- Where do you want Bill Gates to go today? -- From a Slashdot.org post From russell at coker.com.au Fri Feb 3 05:26:43 2006 From: russell at coker.com.au (Russell Coker) Date: Fri, 3 Feb 2006 16:26:43 +1100 Subject: Booting problems with kernel and selinux In-Reply-To: <20060203022255.DKVU23047.ibm69aec.bellsouth.net@mail.bellsouth.net> References: <20060203022255.DKVU23047.ibm69aec.bellsouth.net@mail.bellsouth.net> Message-ID: <200602031626.50237.russell@coker.com.au> On Friday 03 February 2006 13:22, louisg00 at bellsouth.net wrote: > > touch /.autorelabel > > reboot > > I did a relabel but still having problems. This is what I get: Did you boot with enforcing=0 for the relabel? Sometimes mislabelling can prevent the relabelling from occurring. > Feb 2 20:53:29 soncomputer kernel: audit(1138931589.627:32): avc: denied > { search } for pid=2095 comm="avahi-daemon" name="/" dev=hda3 ino=2 > scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:file_t:s0 > tclass=dir Feb 2 20:53:30 soncomputer kernel: audit(1138931589.627:33): What is /dev/hda3? The root file system? If the root directory is unlabeled then things are seriously messed up and in need of a relabel. -- 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 Feb 3 06:56:20 2006 From: naoki at valuecommerce.com (Naoki) Date: Fri, 03 Feb 2006 15:56:20 +0900 Subject: Input method : was - rawhide report: 20060202 changes In-Reply-To: <20060203131906.6f98678b.petersen@redhat.com> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> <1138896089.15099.6.camel@kloczek01.pracownicy.zie> <20060202172433.2a79d274@python2> <20060202164652.GA5019@devserv.devel.redhat.com> <1138915939.15099.34.camel@kloczek01.pracownicy.zie> <20060202215045.GA28604@devserv.devel.redhat.com> <1138919039.25983.3.camel@kloczek01.pracownicy.zie> <20060202222925.GB4172@devserv.devel.redhat.com> <1138920722.25983.9.camel@kloczek01.pracownicy.zie> <20060203131906.6f98678b.petersen@redhat.com> Message-ID: <1138949780.2553.1.camel@dragon.sys.intra> Howdy, I see FC5 is moving to SCIM as the default input method, and I'd love to give it a go. However we seem to be missing the Japanese tables ( I recall seeing a "ja" and a "japanese" a couple of weeks back?). Are these coming back or should I be doing it another way? Cheers. On Fri, 2006-02-03 at 13:19 +0900, Jens Petersen wrote: > On Thu, 02 Feb 2006 23:52:02 +0100 > Tomasz K?oczko wrote: > > > So why m17n-db not supports *only* that scim-tables not supported > > languages ? > > Well in the ideal world yes, and I think will be the tendency in the > long run: when I've finished porting the Indian tables in scim-tables > to m17n-db, I think they can be removed from scim-tables: certainly I > plan to do that for the Fedora package. > > > Using m17n-lib without m17n-db do not have sense so packaging this in > > separated binary package also (IMO) do not have sense. > > Well it makes sense from the point of view of updates: it makes it > possible to add some input maps to m17n-db or update the version > without forcing people to have to update their m17n-lib packages for no > reason, and vice versa. I don't see any advantage in merging the > packages together. > > Jens From t.matsuu at gmail.com Fri Feb 3 07:02:06 2006 From: t.matsuu at gmail.com (MATSUURA Takanori) Date: Fri, 3 Feb 2006 16:02:06 +0900 Subject: Bad selinux policy? Message-ID: <6f27515e0602022302j274040dbg@mail.gmail.com> I'm now testing FC5T2. When I updated selinux-policy-targeted to 2.2.9-2, security contexts of .so files in Adobe Reader, SUN JDK, and macromedia flash are changed and binaries are not worked. What happened with selinux-policy-targeted? MATSUURA Takanori From nigel.metheringham at dev.intechnology.co.uk Fri Feb 3 09:04:02 2006 From: nigel.metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Fri, 03 Feb 2006 09:04:02 +0000 Subject: e1000 in rawhide kernel In-Reply-To: <1138925360.3728.5.camel@nemausa.et.endace.com> References: <1138925360.3728.5.camel@nemausa.et.endace.com> Message-ID: <1138957442.21385.2.camel@localhost.localdomain> On Fri, 2006-02-03 at 13:08 +1300, Michael J Knox wrote: > I have a 82573E onboard NIC that refuses to obtain a DHCP IP. If its > statically asigned, I am ok. Try getting the port you are connected to set to (say) 100 MB FD with no autonegotiation, and see if that works better. Some network switches/NIC combos seem to take for ever to negotiate the link. Quite whose fault this is I don't know, although one network equipment manufacturer seems to be always involved. Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From pbrobinson at gmail.com Fri Feb 3 09:16:18 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 3 Feb 2006 09:16:18 +0000 Subject: e1000 in rawhide kernel In-Reply-To: <1138957442.21385.2.camel@localhost.localdomain> References: <1138925360.3728.5.camel@nemausa.et.endace.com> <1138957442.21385.2.camel@localhost.localdomain> Message-ID: <5256d0b0602030116l2f1415daofaa13ab36f7d22f3@mail.gmail.com> On 2/3/06, Nigel Metheringham wrote: > On Fri, 2006-02-03 at 13:08 +1300, Michael J Knox wrote: > > I have a 82573E onboard NIC that refuses to obtain a DHCP IP. If its > > statically asigned, I am ok. > > Try getting the port you are connected to set to (say) 100 MB FD with no > autonegotiation, and see if that works better. Some network > switches/NIC combos seem to take for ever to negotiate the link. Quite > whose fault this is I don't know, although one network equipment > manufacturer seems to be always involved. The higher end ones take ages to negotiate because they try and neg Spanning Tree Protocol first so the port goes through a blocking, discovery and then is finally into the forwarding stage. This normally doesn't cause a problem with newer NICs but it use to be very painful on older NICs with Netware as the netware drivers would time out. Not sure if this would be an issue but one other thing to look at is to make sure your not running and extremely tight custom firewall that blocks the dhcp response packets. Also does it work if you temporarily set a static IP. Pete From kloczek at zie.pg.gda.pl Fri Feb 3 09:34:17 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=) Date: Fri, 03 Feb 2006 10:34:17 +0100 Subject: propozition of specs cleanups Message-ID: <1138959257.25983.84.camel@kloczek01.pracownicy.zie> IMO it will be good perform some spec files cleanups. Patch with this cleanups is relative large and it touches many spec files (it will be hard submiting this using bugzilla) but all can be changed using single sed line: [devel]$ sed -i '/^%doc$/d; /^%doc $/d; \ s/^%doc %{_mandir}/%{_mandir}/; \ s/\(^%{_mandir}\/.*\)\(\.gz$\)/\1\*/' \ */*spec Above: - removes empty %doc lines, - removes %doc from %{_mandir}/* %files entries (all %{_mandir} entries are marked by default as %doc), - replace .gz suffix by * from %{_mandir}/* entries This allow choose on build stage generate binary packages with or without gzipped man pages. kloczek From clovis at agr.unicamp.br Fri Feb 3 09:40:13 2006 From: clovis at agr.unicamp.br (Clovis Tristao) Date: Fri, 03 Feb 2006 07:40:13 -0200 Subject: Yum question In-Reply-To: <1138898098.23767.19.camel@ignacio.lan> References: <43E2328D.9090109@agr.unicamp.br> <1138898098.23767.19.camel@ignacio.lan> Message-ID: <43E324FD.7000801@agr.unicamp.br> Ignacio Vazquez-Abrams wrote: > On Thu, 2006-02-02 at 14:25 -0200, Clovis Tristao wrote: > >> What's happening? >> > > Exactly what's expected given the Rawhide report from yesterday. > > Hi, Thanks for your reply, today yum update was realized. It's Rawhide world :-)) Cheers, Cl?vis -- Clovis Tristao - UNICAMP/Faculdade de Engenharia Agricola Administrador de Redes - Secao de Informatica (SINFO) E-mail: mailto:clovis at agr.unicamp.br http://www.agr.unicamp.br Fone(0xx19) 37881031-37881038 ou FAX(55xx19) 37881005/37881010 -------------- next part -------------- An HTML attachment was scrubbed... URL: From petersen at redhat.com Fri Feb 3 09:45:35 2006 From: petersen at redhat.com (Jens Petersen) Date: Fri, 3 Feb 2006 18:45:35 +0900 Subject: Input method : was - rawhide report: 20060202 changes In-Reply-To: <1138949780.2553.1.camel@dragon.sys.intra> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> <1138896089.15099.6.camel@kloczek01.pracownicy.zie> <20060202172433.2a79d274@python2> <20060202164652.GA5019@devserv.devel.redhat.com> <1138915939.15099.34.camel@kloczek01.pracownicy.zie> <20060202215045.GA28604@devserv.devel.redhat.com> <1138919039.25983.3.camel@kloczek01.pracownicy.zie> <20060202222925.GB4172@devserv.devel.redhat.com> <1138920722.25983.9.camel@kloczek01.pracownicy.zie> <20060203131906.6f98678b.petersen@redhat.com> <1138949780.2553.1.camel@dragon.sys.intra> Message-ID: <20060203184535.ff236bec.petersen@redhat.com> On Fri, 03 Feb 2006 15:56:20 +0900 Naoki wrote: > I see FC5 is moving to SCIM as the default input method, and I'd love to > give it a go. However we seem to be missing the Japanese tables ( I > recall seeing a "ja" and a "japanese" a couple of weeks back?). You're referring to scim-tables-japanese? It was removed because the Japanese tables in scim-tables are not really usable for Japanese input. You want scim-anthy, which is also in Fedora Extras for FC3 and FC4. Jens From mharris at mharris.ca Fri Feb 3 09:56:38 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Fri, 03 Feb 2006 04:56:38 -0500 Subject: Rawhide performance? In-Reply-To: <43E1D00F.2040807@pvv.org> References: <1138835047.3324.91.camel@mentorng.gurulabs.com> <43E1D00F.2040807@pvv.org> Message-ID: <43E328D6.7010309@mharris.ca> Trond Eivind Glomsr?d wrote: > Dax Kelson wrote: > >> I installed rawhide on a beefy desktop computer. >> >> AMD FX-55 CPU >> 2GB RAM >> 300GB SATA RAID1 (testing out the new dmraid integration) >> Nvidia 6800GT 256MB video (Qty 2 -- SLI) >> 1600x1200 resolution >> >> I haven't quantified it yet, but desktop GNOME performance seems very >> sluggish. Many seconds to launch apps. Many seconds for the GNOME panel >> menu to drop down and populate with icons. In general the lack of >> performance is bad enough to be very noticeable and annoying. > > One trick which improved performance from what you describe to ok for > me, was rerunning fc-cache - I had a directory of fonts in my home > directory, and it seemed to parse them every time something started. At some point in FC5 development, a fontconfig update seems to have been rather buggy, and caused performance problems also. I don't know the details, but the package maintainer and others have alluded to this, and runtime behaviour was certainly suggestive of it as well. Upon Matthias' request (fontconfig maintainer), I have removed the fc-cache call from the xfs initscript, which should improve system boot time, as it no longer mandatorily calls fc-cache. We're now relying on font rpm packages to invoke fc-cache directly from %post and %postun instead. While this is not directly related to the thread, part of the reason for the removal, is that I'm told that if fonts.cache-* files are not present, fc-cache will get ran automatically at runtime to generate them, but on a per-user basis instead of systemwide. That's useful for user ~/.fonts directories if it works, but it sounds like it doesn't work from what you're saying. If that's the case, it's likely to be a fontconfig bug IMHO. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Fri Feb 3 10:04:30 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Fri, 03 Feb 2006 05:04:30 -0500 Subject: nothing from buildsys? In-Reply-To: <5256d0b0602020239s3aa68266p37346bfc4d493c12@mail.gmail.com> References: <43E1E0BE.2080908@adslpipe.co.uk> <5256d0b0602020239s3aa68266p37346bfc4d493c12@mail.gmail.com> Message-ID: <43E32AAE.2030703@mharris.ca> Peter Robinson wrote: >>Is buildsys still working on today's bake, or is there some other reason >>why no new rawhide today? > > > If there's a lot of rebuilds it sometimes doesn't appear until around > midday GMT time so it's probably still toiling away on the builds. I > saw on a blog somewhere that one of the redhat guys is playing with a > unified accross all platforms srpm repo so it could be due to that. SRPMS have been unified across all architectures since about Red Hat Linux 7.2 or 7.3 at Red Hat. Or in other words, when a single src.rpm package is built, it is simultaneously submitted to all 7 of the architectures in the buildsystem to which are considered the "primary architectures". Essentially, these are the architectures which RHEL is available for. If a build fails on any one architecture, a signal is sent to the builds on all other architectures to kill them and discard all results. The consequence of this, is that ever since that has been implemented in the Red Hat build system, every single package built, is built on all 7 architectures, or on 0 architectures. Package failures require the engineer to fix the package until it builds on all 7 arches in order for it to be accepted into the buildsystem. The only exceptions to this, are: 1) Packages that are by their very nature, architecture specific or which don't make sense on some architectures. 2) Packages that fail on an architecture due to buildsystem breakage or other obscure problem, so the engineer excludes the arch from being built using ExclusiveArch/ExcludeArch in the spec file to temporarily work around the problem until someone else can fix the broken buildmachines, etc. So.... What is this unified across all platforms srpm repo you speak of, and how does it differ from what we've been doing internally for about 4 years? ;o) -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From pbrobinson at gmail.com Fri Feb 3 10:11:59 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 3 Feb 2006 10:11:59 +0000 Subject: nothing from buildsys? In-Reply-To: <43E32AAE.2030703@mharris.ca> References: <43E1E0BE.2080908@adslpipe.co.uk> <5256d0b0602020239s3aa68266p37346bfc4d493c12@mail.gmail.com> <43E32AAE.2030703@mharris.ca> Message-ID: <5256d0b0602030211k2631d39cgbbc767d5fb29fbcd@mail.gmail.com> On 2/3/06, Mike A. Harris wrote: > Peter Robinson wrote: > >>Is buildsys still working on today's bake, or is there some other reason > >>why no new rawhide today? > > > > > > If there's a lot of rebuilds it sometimes doesn't appear until around > > midday GMT time so it's probably still toiling away on the builds. I > > saw on a blog somewhere that one of the redhat guys is playing with a > > unified accross all platforms srpm repo so it could be due to that. > > SRPMS have been unified across all architectures since about > Red Hat Linux 7.2 or 7.3 at Red Hat. Or in other words, when > a single src.rpm package is built, it is simultaneously submitted > to all 7 of the architectures in the buildsystem to which are > considered the "primary architectures". Essentially, these are > the architectures which RHEL is available for. > > If a build fails on any one architecture, a signal is sent to > the builds on all other architectures to kill them and discard > all results. > > The consequence of this, is that ever since that has been implemented > in the Red Hat build system, every single package built, is built on > all 7 architectures, or on 0 architectures. Package failures require > the engineer to fix the package until it builds on all 7 arches in > order for it to be accepted into the buildsystem. The only exceptions > to this, are: > > 1) Packages that are by their very nature, architecture specific > or which don't make sense on some architectures. > > 2) Packages that fail on an architecture due to buildsystem breakage > or other obscure problem, so the engineer excludes the arch from > being built using ExclusiveArch/ExcludeArch in the spec file to > temporarily work around the problem until someone else can fix > the broken buildmachines, etc. > > So.... What is this unified across all platforms srpm repo you speak > of, and how does it differ from what we've been doing internally for > about 4 years? ;o) Digging back through my rss feeds it was this post to p.f.o from Jesse http://jkeating.livejournal.com/14754.html Pete From louisg00 at bellsouth.net Fri Feb 3 09:57:09 2006 From: louisg00 at bellsouth.net (Louis E Garcia II) Date: Fri, 03 Feb 2006 04:57:09 -0500 Subject: Booting problems with kernel and selinux In-Reply-To: <200602031626.50237.russell@coker.com.au> References: <20060203022255.DKVU23047.ibm69aec.bellsouth.net@mail.bellsouth.net> <200602031626.50237.russell@coker.com.au> Message-ID: <1138960629.2688.19.camel@soncomputer> On Fri, 2006-02-03 at 16:26 +1100, Russell Coker wrote: > On Friday 03 February 2006 13:22, louisg00 at bellsouth.net wrote: > > > touch /.autorelabel > > > reboot > > > > I did a relabel but still having problems. This is what I get: > > Did you boot with enforcing=0 for the relabel? Sometimes mislabelling can > prevent the relabelling from occurring. I relabeled in permissive mode and it went fine. Fixed a lot but not all problems. > > Feb 2 20:53:29 soncomputer kernel: audit(1138931589.627:32): avc: denied > > { search } for pid=2095 comm="avahi-daemon" name="/" dev=hda3 ino=2 > > scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:file_t:s0 > > tclass=dir Feb 2 20:53:30 soncomputer kernel: audit(1138931589.627:33): > > What is /dev/hda3? The root file system? If the root directory is unlabeled > then things are seriously messed up and in need of a relabel. /dev/hd3 is my root partition. After the relabel things quieted down. This is the relevant entries during boot now. In enforcing mode the system was unable to mount the /boot and /home partitions. kernel: Security Framework v1.0.0 initialized kernel: SELinux: Initializing. kernel: SELinux: Starting in permissive mode kernel: selinux_register_security: Registering secondary module capability kernel: Capability LSM initialized as secondary kernel: SELinux: Registering netfilter hooks kernel: security: 3 users, 6 roles, 1125 types, 132 bools, 1 sens, 256 cats kernel: security: 55 classes, 37291 rules kernel: SELinux: Completing initialization. kernel: SELinux: Setting up existing superblocks. kernel: SELinux: initialized (dev hda3, type ext3), uses xattr kernel: inode_doinit_with_dentry: context_to_sid(unlabeled) returned 22 for dev=hda3 ino=1562113 kernel: inode_doinit_with_dentry: context_to_sid(unlabeled) returned 22 for dev=hda3 ino=618337 kernel: inode_doinit_with_dentry: context_to_sid(unlabeled) returned 22 for dev=hda3 ino=585793 kernel: inode_doinit_with_dentry: context_to_sid(unlabeled) returned 22 for dev=hda3 ino=1594657 kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs kernel: SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts kernel: SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts kernel: SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs kernel: SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses genfs_contexts kernel: SELinux: initialized (dev devpts, type devpts), uses transition SIDs kernel: SELinux: initialized (dev eventpollfs, type eventpollfs), uses genfs_contexts kernel: SELinux: initialized (dev inotifyfs, type inotifyfs), uses genfs_contexts kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs kernel: SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts kernel: SELinux: initialized (dev pipefs, type pipefs), uses task SIDs kernel: SELinux: initialized (dev sockfs, type sockfs), uses task SIDs kernel: SELinux: initialized (dev proc, type proc), uses genfs_contexts kernel: SELinux: initialized (dev bdev, type bdev), uses genfs_contexts kernel: SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts kernel: SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts kernel: inode_doinit_with_dentry: context_to_sid(unlabeled) returned 22 for dev=hda3 ino=1050728 kernel: SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts kernel: SELinux: initialized (dev ramfs, type ramfs), uses genfs_contexts kernel: inode_doinit_with_dentry: context_to_sid(unlabeled) returned 22 for dev=hda3 ino=195265 kernel: inode_doinit_with_dentry: context_to_sid(unlabeled) returned 22 for dev=hda3 ino=683425 kernel: audit(1138958718.999:2): avc: denied { mounton } for pid=1462 comm="mount" name="boot" dev=hda3 ino=195265 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir kernel: audit(1138958718.999:3): avc: denied { mounton } for pid=1462 comm="mount" name="boot" dev=hda3 ino=195265 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs kernel: audit(1138958719.003:4): avc: denied { mounton } for pid=1462 comm="mount" name="home" dev=hda3 ino=683425 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir kernel: audit(1138958719.003:5): avc: denied { mounton } for pid=1462 comm="mount" name="home" dev=hda3 ino=683425 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir kernel: SELinux: initialized (dev hda1, type ntfs), uses genfs_contexts Feb 3 04:25:39 soncomputer kernel: Adding 1020088k swap on /dev/hda5. Priority:-1 extents:1 across:1020088k kernel: SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses genfs_contexts kernel: audit(1138958720.667:6): avc: granted { execmem } for pid=1550 comm="kudzu" scontext=system_u:system_r:kudzu_t:s0 tcontext=system_u:system_r:kudzu_t:s0 tclass=process kernel: audit(1138958720.667:7): avc: granted { execmem } for pid=1550 comm="kudzu" scontext=system_u:system_r:kudzu_t:s0 tcontext=system_u:system_r:kudzu_t:s0 tclass=process kernel: audit(1138958722.099:8): avc: denied { read } for pid=1541 comm="readahead" name="display" dev=ramfs ino=4029 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:ramfs_t:s0 tclass=file kernel: audit(1138958722.099:9): avc: denied { read } for pid=1541 comm="readahead" name="rhgb-console" dev=ramfs ino=4107 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:ramfs_t:s0 tclass=fifo_file kernel: audit(1138958725.539:10): avc: denied { read } for pid=1541 comm="readahead" name="display" dev=ramfs ino=4029 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:ramfs_t:s0 tclass=file kernel: audit(1138958725.539:11): avc: denied { read } for pid=1541 comm="readahead" name="rhgb-console" dev=ramfs ino=4107 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:ramfs_t:s0 tclass=fifo_file kernel: inode_doinit_with_dentry: context_to_sid(unlabeled) returned 22 for dev=hda3 ino=1822979 kernel: audit(1138958733.996:12): avc: denied { mounton } for pid=1815 comm="mount" name="rpc_pipefs" dev=hda3 ino=1822979 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir kernel: audit(1138958733.996:13): avc: denied { mounton } for pid=1815 comm="mount" name="rpc_pipefs" dev=hda3 ino=1822979 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir kernel: SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts kernel: SELinux: initialized (dev 0:14, type nfs), uses genfs_contexts Feb 3 04:25:39 soncomputer kernel: audit(1138958734.600:14): avc: denied { mounton } for pid=1858 comm="mount" name="boot" dev=hda3 ino=195265 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir kernel: audit(1138958734.600:15): avc: denied { mounton } for pid=1858 comm="mount" name="boot" dev=hda3 ino=195265 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir kernel: audit(1138958734.600:16): avc: denied { mounton } for pid=1858 comm="mount" name="home" dev=hda3 ino=683425 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir kernel: audit(1138958734.600:17): avc: denied { mounton } for pid=1858 comm="mount" name="home" dev=hda3 ino=683425 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir kernel: SELinux: initialized (dev autofs, type autofs), uses genfs_contexts kernel: inode_doinit_with_dentry: context_to_sid(unlabeled) returned 22 for dev=hda3 ino=1985186 kernel: inode_doinit_with_dentry: context_to_sid(unlabeled) returned 22 for dev=hda3 ino=1985189 From mharris at mharris.ca Fri Feb 3 10:15:54 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Fri, 03 Feb 2006 05:15:54 -0500 Subject: nothing from buildsys? In-Reply-To: <43E1F427.3050701@reub.net> References: <43E1E0BE.2080908@adslpipe.co.uk> <5256d0b0602020239s3aa68266p37346bfc4d493c12@mail.gmail.com> <43E1F427.3050701@reub.net> Message-ID: <43E32D5A.5050907@mharris.ca> Reuben Farrelly wrote: > > > On 2/02/2006 11:39 p.m., Peter Robinson wrote: > >>> Is buildsys still working on today's bake, or is there some other reason >>> why no new rawhide today? >> >> >> If there's a lot of rebuilds it sometimes doesn't appear until around >> midday GMT time so it's probably still toiling away on the builds. I >> saw on a blog somewhere that one of the redhat guys is playing with a >> unified accross all platforms srpm repo so it could be due to that. > > > Every time a nasty bug shows up in rawhide (like the one with yum and > python-sqlite from yesterday) I wonder if it would be possible or in > fact practical to have two builds a day or more to pick up rawhide changes. > Is there a reason why only 1 a day is done - is it just historical? Rawhide compose begins at 2:00am EST or so I'm told. My understanding, is that it is done at 2:00am because that is a time of day which the buildsystems and infrastructure is usually the least busy, and has the least number of engineers using it (if any), so it is not disruptive to the regular flow of daily engineering that is happening. If rawhide were to be composed every 12 hours instead, it would hit at 2:00am, and 2:00pm then, and most likely would lower everyone's productivity horrendously, due to the increased load on the buildsystem infrastructure. > I'd also be curious to know what sort of machine is doing the actual > building, one would expect that given sometimes there are builds of gcc > and glibc on the go in one nightly build, it must be a seriously fast > piece of machinery to be able to produce so many binaries in a > reasonable amount of time. Anyone who has tried compiling glibc from > scratch would testify how long that alone can take ;-) The buildsystem infrastructure consists of numerous computers. The primary hub, is our infamous "porkchop", which is an SMP x86 box that is the entranceway to the buildsystem and various other infrastructure. Jobs submitted to the buildsystem (beehive) on porkchop, get enqueued to be farmed out to all 7 architectures simultaneously, and the actual builds occur on each architecture as a machine in the build pool is free and available to accept a job. All of the buildmachines are SMP hardware with 2-8 CPUs (possibly 16 CPUs on occasion, not sure), with whackloads of RAM. While the whole setup is sometimes idle, more often than not, it is very busy building whackloads of packages for Fedora, RHEL updates, and running various automated tests and other stuff. Tree composes, and various other RELENG stuff also pounds the machines into the ground, as do automated mass-rebuilds and other fun stuff. Nonetheless, even with this much total computing power available, due to the high load on the systems, it isn't always what you might consider "fast" overall. For example, I can build Xorg on my personal workstation here at home in about 15 minutes completely, however the same rpm takes anywhere from 1.5 hours to 3 or more hours going through the buildsystem even when it's idle (usually due to s390/s390x/ia64 taking forever to compile). Anyhow, I figured I'd share a bit of mumbo-jumbo about the buildsystem, as people often ask, and don't always get much info. ;) If you've got a 1.5Ghz CPU or faster, and install "ccache" from Fedora Extras, your machine will build pretty much any package faster than our buildsystem. ;o) -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Fri Feb 3 10:27:56 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Fri, 03 Feb 2006 05:27:56 -0500 Subject: propozition of specs cleanups In-Reply-To: <1138959257.25983.84.camel@kloczek01.pracownicy.zie> References: <1138959257.25983.84.camel@kloczek01.pracownicy.zie> Message-ID: <43E3302C.2070602@mharris.ca> Tomasz K?oczko wrote: > IMO it will be good perform some spec files cleanups. Patch with this > cleanups is relative large and it touches many spec files (it will be > hard submiting this using bugzilla) but all can be changed using single > sed line: > > [devel]$ sed -i '/^%doc$/d; /^%doc $/d; \ > s/^%doc %{_mandir}/%{_mandir}/; \ > s/\(^%{_mandir}\/.*\)\(\.gz$\)/\1\*/' \ > */*spec > > Above: > - removes empty %doc lines, While that cleans up a line that might be currently unused, it doesn't have any real functional change, and some packages might include that as a reminder to fill in the documentation in a future package update. For example, when I'm creating new rpms, sometimes I am in a hurry to get a useable package out the door and into rawhide ASAP, but there's no reason to make the package 100% perfect, so I generate a spec from a template I use, and fill in the missing pieces over time. This is one thing I find useful when editing a package, that says to me "Mike, you put an empty %doc, which means you have not yet investigated the package closely to see if there is something that should be in %doc. Please do that at some point." That's fairly useful. ;o) For the record, I believe many of the modular X packages fit this category. > - removes %doc from %{_mandir}/* %files entries (all %{_mandir} entries > are marked by default as %doc), That's sensible. > - replace .gz suffix by * from %{_mandir}/* entries > This allow choose on build stage generate binary packages with or > without gzipped man pages. Yep, that is general good RPM housekeeping. I think the best thing to do, is to have some global rpmlint-like tests run in our buildsystem that look for these types of uglyisms, and force them to be fixed in order for the package to build. (pre-tests) While it would have some value, and could be enhanced over time with other tests, it'd also likely be low priority overall compared to other work that needs doing.. Best thing for people to do, is to generate patches and submit them to bugzilla for now. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Fri Feb 3 10:36:52 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Fri, 03 Feb 2006 05:36:52 -0500 Subject: nothing from buildsys? In-Reply-To: <5256d0b0602030211k2631d39cgbbc767d5fb29fbcd@mail.gmail.com> References: <43E1E0BE.2080908@adslpipe.co.uk> <5256d0b0602020239s3aa68266p37346bfc4d493c12@mail.gmail.com> <43E32AAE.2030703@mharris.ca> <5256d0b0602030211k2631d39cgbbc767d5fb29fbcd@mail.gmail.com> Message-ID: <43E33244.7080605@mharris.ca> Peter Robinson wrote: > On 2/3/06, Mike A. Harris wrote: > >>So.... What is this unified across all platforms srpm repo you speak >>of, and how does it differ from what we've been doing internally for >>about 4 years? ;o) > > > Digging back through my rss feeds it was this post to p.f.o from Jesse > http://jkeating.livejournal.com/14754.html Ahhh, I see. I'm refering to the src.rpm's that are /input/ into the buildsystem to build the OS on all arches. I didn't realize the SRPMS disks we made had different contents per-architecture due to this on the /output/ side of things. ;o) Yes, it would definitely be smart to have one ginormic SRPMS disk. ;) As a total side-question though, just for personal curiousity... 1) How many people actually download the SRPMS disk images? 2) How many people actually really use them for anything? I always wondered that, because a long time ago, I used to download them all and burn them, until I realized that I never actually ever used them. ;o) I always downloaded the latest src.rpm from the ftp server if I needed it, as that way I ensured I was using the latest one. I suppose the answer likely varies by global location, and the cost of internet access in any particular place though. Anyhoo... back to your regularly scheduled program... ;) -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From kloczek at zie.pg.gda.pl Fri Feb 3 11:16:57 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=) Date: Fri, 03 Feb 2006 12:16:57 +0100 Subject: propozition of specs cleanups In-Reply-To: <43E3302C.2070602@mharris.ca> References: <1138959257.25983.84.camel@kloczek01.pracownicy.zie> <43E3302C.2070602@mharris.ca> Message-ID: <1138965417.25983.133.camel@kloczek01.pracownicy.zie> Dnia 03-02-2006, pi? o godzinie 05:27 -0500, Mike A. Harris napisa?(a): [..] > While that cleans up a line that might be currently unused, it > doesn't have any real functional change, and some packages might > include that as a reminder to fill in the documentation in a future > package update. For example, when I'm creating new rpms, sometimes > I am in a hurry to get a useable package out the door and into > rawhide ASAP, but there's no reason to make the package 100% perfect, > so I generate a spec from a template I use, and fill in the missing > pieces over time. I'm working on variouse rpm packages more than nine years (I supose this is more than two time or longer than you; still you can find many my packages in RH contrib). Your recent xorg* packages are very *badly* written (sorry but it looks for me like this your first bigger work on maintaining spec files .. or as you don't know for what can be used awk/sed/perl ;>). All ot them have many lines which are can be dropped without removing single usable functionality but which allow meke spec files more readable like stupid comments (probaly placing comments was take more time than verify all this %doc), placing in %fiels %{_bindir}, %{_mandir} and similar ad %dir .. THIS directories are in filesystem, %{_datadir}/aclocal which belongs to autoconf ... many, many simillar things :>. Do you wan't more sed lines ? :) Look .. most of empty %doc are in xorg* so please don't try defent this as reminder or so .. you metodology for me shows as bad it is :> Trust me .. by this you spend on this much more time than it requires. And probably some %doc reminder will be never removed because you will have each time much more importand things. Quality of package/spec file as same as .c file strongly depends on first impmentation. Most of this kind "bugs" can be fixed using single sed line. Again: do you wan't more sed lines ? :) > This is one thing I find useful when editing a package, that says > to me "Mike, you put an empty %doc, which means you have not yet > investigated the package closely to see if there is something that > should be in %doc. Please do that at some point." That's fairly > useful. ;o) Verry usefull .. for start look on you as bad developer ;> Sorry .. > > - replace .gz suffix by * from %{_mandir}/* entries > > This allow choose on build stage generate binary packages with or > > without gzipped man pages. > > Yep, that is general good RPM housekeeping. I think the best thing > to do, is to have some global rpmlint-like tests run in our buildsystem > that look for these types of uglyisms, and force them to be fixed in > order for the package to build. (pre-tests) > > While it would have some value, and could be enhanced over time with > other tests, it'd also likely be low priority overall compared to > other work that needs doing.. > > Best thing for people to do, is to generate patches and submit them > to bugzilla for now. Please don't be crazy ;> Diffstat for submitted chages: [devel]$ cvs diff -u | diffstat .diff | tail -n 1 86 files changed, 225 insertions(+), 280 deletions(-) ^^ few seconds on thinkig on sed line you want "convert" to few hours sitting on bugzilla which will generate next few hours/person for closing and commiting all this very simple/elementar changes. Plain stupidity :> I'm mailing to this list for introduce this in cvs tree in possible shorter time frame .. please don't say me "go to /dev/bugzilla^Wtree or and try game with your balls" .. ;>) Commiting this do not require immediate rebuilding each 86 packages. kloczek From gnomeuser at gmail.com Fri Feb 3 11:24:47 2006 From: gnomeuser at gmail.com (David Nielsen) Date: Fri, 03 Feb 2006 12:24:47 +0100 Subject: propozition of specs cleanups In-Reply-To: <1138965417.25983.133.camel@kloczek01.pracownicy.zie> References: <1138959257.25983.84.camel@kloczek01.pracownicy.zie> <43E3302C.2070602@mharris.ca> <1138965417.25983.133.camel@kloczek01.pracownicy.zie> Message-ID: <1138965888.2543.2.camel@price.stavtrup-st.dk> fre, 03 02 2006 kl. 12:16 +0100, skrev Tomasz K?oczko: > > I'm mailing to this list for introduce this in cvs tree in possible > shorter time frame .. please don't say me "go to /dev/bugzilla^Wtree or > and try game with your balls" .. ;>) > Commiting this do not require immediate rebuilding each 86 packages. Did you possibly forget to take some kind of medication? - David -- Obligatory shameless blog plug - the GNOME commentary located at: www.lovesunix.net/blog From sundaram at fedoraproject.org Fri Feb 3 11:41:10 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 03 Feb 2006 17:11:10 +0530 Subject: propozition of specs cleanups In-Reply-To: <1138965417.25983.133.camel@kloczek01.pracownicy.zie> References: <1138959257.25983.84.camel@kloczek01.pracownicy.zie> <43E3302C.2070602@mharris.ca> <1138965417.25983.133.camel@kloczek01.pracownicy.zie> Message-ID: <43E34156.9030402@fedoraproject.org> Tomasz K?oczko wrote: >Dnia 03-02-2006, pi? o godzinie 05:27 -0500, Mike A. Harris napisa?(a): >[..] > > >>While that cleans up a line that might be currently unused, it >>doesn't have any real functional change, and some packages might >>include that as a reminder to fill in the documentation in a future >>package update. For example, when I'm creating new rpms, sometimes >>I am in a hurry to get a useable package out the door and into >>rawhide ASAP, but there's no reason to make the package 100% perfect, >>so I generate a spec from a template I use, and fill in the missing >>pieces over time. >> >> > >I'm working on variouse rpm packages more than nine years (I supose this >is more than two time or longer than you; still you can find many my >packages in RH contrib). > >Your recent xorg* packages are very *badly* written (sorry but it looks >for me like this your first bigger work on maintaining spec files .. or >as you don't know for what can be used awk/sed/perl ;>). >All ot them have many lines which are can be dropped without removing >single usable functionality but which allow meke spec files more >readable like stupid comments (probaly placing comments was take more >time than verify all this %doc), placing in %fiels %{_bindir}, >%{_mandir} and similar ad %dir .. THIS directories are in filesystem, >%{_datadir}/aclocal which belongs to autoconf ... many, many simillar >things :>. > >Do you wan't more sed lines ? :) > >Look .. most of empty %doc are in xorg* so please don't try defent this >as reminder or so .. you metodology for me shows as bad it is :> >Trust me .. by this you spend on this much more time than it requires. >And probably some %doc reminder will be never removed because you will >have each time much more importand things. >Quality of package/spec file as same as .c file strongly depends on >first impmentation. > >Most of this kind "bugs" can be fixed using single sed line. >Again: do you wan't more sed lines ? :) > > > >>This is one thing I find useful when editing a package, that says >>to me "Mike, you put an empty %doc, which means you have not yet >>investigated the package closely to see if there is something that >>should be in %doc. Please do that at some point." That's fairly >>useful. ;o) >> >> > >Verry usefull .. for start look on you as bad developer ;> >Sorry .. > > > >>>- replace .gz suffix by * from %{_mandir}/* entries >>> This allow choose on build stage generate binary packages with or >>> without gzipped man pages. >>> >>> >>Yep, that is general good RPM housekeeping. I think the best thing >>to do, is to have some global rpmlint-like tests run in our buildsystem >>that look for these types of uglyisms, and force them to be fixed in >>order for the package to build. (pre-tests) >> >>While it would have some value, and could be enhanced over time with >>other tests, it'd also likely be low priority overall compared to >>other work that needs doing.. >> >>Best thing for people to do, is to generate patches and submit them >>to bugzilla for now. >> >> > >Please don't be crazy ;> >Diffstat for submitted chages: >[devel]$ cvs diff -u | diffstat .diff | tail -n 1 > 86 files changed, 225 insertions(+), 280 deletions(-) > ^^ > >few seconds on thinkig on sed line you want "convert" to few hours >sitting on bugzilla which will generate next few hours/person for >closing and commiting all this very simple/elementar changes. >Plain stupidity :> > >I'm mailing to this list for introduce this in cvs tree in possible >shorter time frame .. please don't say me "go to /dev/bugzilla^Wtree or >and try game with your balls" .. ;>) >Commiting this do not require immediate rebuilding each 86 packages. > >kloczek > > You might have a point but this is pretty rude way to express it. --- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From kloczek at zie.pg.gda.pl Fri Feb 3 12:11:59 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=) Date: Fri, 03 Feb 2006 13:11:59 +0100 Subject: propozition of specs cleanups In-Reply-To: <43E34156.9030402@fedoraproject.org> References: <1138959257.25983.84.camel@kloczek01.pracownicy.zie> <43E3302C.2070602@mharris.ca> <1138965417.25983.133.camel@kloczek01.pracownicy.zie> <43E34156.9030402@fedoraproject.org> Message-ID: <1138968719.25983.142.camel@kloczek01.pracownicy.zie> Dnia 03-02-2006, pi? o godzinie 17:11 +0530, Rahul Sundaram napisa?(a): [..] > You might have a point but this is pretty rude way to express it. Good to know you focus on my expression (not on sense chages). If you want my time for spending on bugzilla -> please pay me for this (sorry) or show me how can I introduce in time frame comparable to time spend on thinking on sed line Is RH bugzilla have email interface ? Do you realy want few thousands new bugzilla raports for single lines changes ? I you not .. please put this sed line in /dev/null. kloczek From sundaram at fedoraproject.org Fri Feb 3 12:24:01 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 03 Feb 2006 17:54:01 +0530 Subject: propozition of specs cleanups In-Reply-To: <1138968719.25983.142.camel@kloczek01.pracownicy.zie> References: <1138959257.25983.84.camel@kloczek01.pracownicy.zie> <43E3302C.2070602@mharris.ca> <1138965417.25983.133.camel@kloczek01.pracownicy.zie> <43E34156.9030402@fedoraproject.org> <1138968719.25983.142.camel@kloczek01.pracownicy.zie> Message-ID: <43E34B61.9000809@fedoraproject.org> Tomasz K?oczko wrote: >Dnia 03-02-2006, pi? o godzinie 17:11 +0530, Rahul Sundaram napisa?(a): >[..] > > >>You might have a point but this is pretty rude way to express it. >> >> > >Good to know you focus on my expression (not on sense chages). > > The expression is as atleast as important as the changes being proposed. There is no point in being rude unnecessarily. It certainly cant motivate the developers to get involved to do the changes. >If you want my time for spending on bugzilla -> please pay me for this >(sorry) or show me how can I introduce in time frame comparable to time >spend on thinking on sed line > > It probably can be done within the buildsystem to enforce such things. Meanwhile if you dont want to voluntarily spend the time involved in reporting this changes to the individual developers through bugzilla feel free to drop it but several people have done similar things before. >Is RH bugzilla have email interface ? > No. >Do you realy want few thousands >new bugzilla raports for single lines changes ? > > Each of the maintainers would receive only a single enhancement request with a patch attached through bugzilla for spec cleanups proposed. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From johnny_blue at email.it Fri Feb 3 12:29:21 2006 From: johnny_blue at email.it (Andrea) Date: Fri, 03 Feb 2006 13:29:21 +0100 Subject: flash-plugin missing text on preferences Message-ID: <43E34CA1.4090500@email.it> if I try to modify preference of flash-plugin on firefox I can't see text? to use it I modify in selinux "Allow executables to run with executable stack" and "Allow the use of shared libraries with Text Relocation". url with screeenshots: http://i15.photobucket.com/albums/a396/johnny_blue/fedora-devel/1.png http://i15.photobucket.com/albums/a396/johnny_blue/fedora-devel/2.png Andrea. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Acquista ora Email.it Phone Card e comincia a risparmiare sulle tue telefonate! Clicca e scopri l'offerta Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2684&d=3-2 From dennis at ausil.us Fri Feb 3 12:48:41 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 3 Feb 2006 06:48:41 -0600 Subject: nothing from buildsys? In-Reply-To: <43E33244.7080605@mharris.ca> References: <43E1E0BE.2080908@adslpipe.co.uk> <5256d0b0602030211k2631d39cgbbc767d5fb29fbcd@mail.gmail.com> <43E33244.7080605@mharris.ca> Message-ID: <200602030649.02942.dennis@ausil.us> Once upon a time Friday 03 February 2006 4:36 am, Mike A. Harris wrote: > 1) How many people actually download the SRPMS disk images? > > 2) How many people actually really use them for anything? Only time ive had SRPM disks was with boxed sets of RHL if i need to build something i download the SRPM as needed. I do have alot of SRPMS downloaded for use on no supported arches. -- Dennis Gilmore, RHCE http://www.ausil.us Proud Australian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 3 12:59:22 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 3 Feb 2006 13:59:22 +0100 Subject: Upgrade from old X packages with /usr/X11R6/bin/mkfontdir in %postun Message-ID: <20060203135922.7e410939@python2> Hi, I just ran "yum update" on an FC4 machine to bring it up to date with Rawhide to do some testing and ran into a few quirks. One was VNC's scriplet : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179849 Then, much more tricky... not sure if it's even worth bugzilla'ing since it's clearly a dead end :-( Removing : fonts-xorg-ISO8859-15-100dpi ##################### [708/835] /var/tmp/rpm-tmp.7625: line 3: /usr/X11R6/bin/mkfontdir: No such file or directory error: %postun(fonts-xorg-ISO8859-15-100dpi-6.8.2-1.noarch) scriptlet failed, exit status 127 Removing : fonts-xorg-75dpi ##################### [655/835] /var/tmp/rpm-tmp.29316: line 3: /usr/X11R6/bin/mkfontdir: No such file or directory error: %postun(fonts-xorg-75dpi-6.8.2-1.noarch) scriptlet failed, exit status 127 For those packages' %postun, the stuff in /usr/X11R6/bin/ is obviously gone now, so the failure is expected... and I can't think of any way to sanely fix that. The result is that those packages don't get erased from the local rpm database... Any brilliant ideas? (apart from symlinking stuff in /usr/X11R6/bin/ for FC5...) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1656_FC4 Load : 0.49 0.49 0.56 From t.matsuu at gmail.com Fri Feb 3 13:08:24 2006 From: t.matsuu at gmail.com (MATSUURA Takanori) Date: Fri, 3 Feb 2006 22:08:24 +0900 Subject: Bad selinux policy? In-Reply-To: <6f27515e0602022302j274040dbg@mail.gmail.com> References: <6f27515e0602022302j274040dbg@mail.gmail.com> Message-ID: <6f27515e0602030508v57ea6a5cn@mail.gmail.com> Dear all, Security contexts is rebuilt as the folloing and it recoverd. Sorry for spam. 1. SELinux is disabled using system-config-securitylevel 2. reboot 3. SELinux is enforced using system-config-securitylevel 4. reboot MATSUURA Takanori From d.jacobfeuerborn at conversis.de Fri Feb 3 15:17:12 2006 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Fri, 03 Feb 2006 16:17:12 +0100 Subject: flash-plugin missing text on preferences In-Reply-To: <43E34CA1.4090500@email.it> References: <43E34CA1.4090500@email.it> Message-ID: <43E373F8.6080404@conversis.de> Andrea wrote: > if I try to modify preference of flash-plugin on firefox I can't see text? > > to use it I modify in selinux "Allow executables to run with executable > stack" and "Allow the use of shared libraries with Text Relocation". > > url with screeenshots: > > http://i15.photobucket.com/albums/a396/johnny_blue/fedora-devel/1.png > http://i15.photobucket.com/albums/a396/johnny_blue/fedora-devel/2.png This issue has been reportet upstream but doesn't seem to get a lot of love right now: https://bugzilla.mozilla.org/show_bug.cgi?id=317655 Regards, Dennis From buildsys at redhat.com Fri Feb 3 15:49:29 2006 From: buildsys at redhat.com (Build System) Date: Fri, 3 Feb 2006 10:49:29 -0500 Subject: rawhide report: 20060203 changes Message-ID: <200602031549.k13FnTaM006152@porkchop.devel.redhat.com> New package jakarta-commons-discovery Jakarta Commons Discovery Updated Packages: GConf2-2.13.5-3 --------------- * Thu Feb 02 2006 Christopher Aillon 2.13.5-3 - Use the correct patch ;-) anaconda-10.91.13-1 ------------------- * Thu Feb 02 2006 Jeremy Katz - 10.91.13-1 - Speed up timezone screen (clumens) - Make kickstart interactive mode work (clumens) - Fix package selection screen (clumens) - Add sqlite to traceonly to help http/ftp memory usage - Write out repo config (pnasrat) - Fix colors on boot splashes (#178033) - Select lang groups before going to the screen (#178673) - Clean up handling of grub vs no boot loader (#159658) bsf-0:2.3.0-6jpp_2fc.2 ---------------------- * Thu Feb 02 2006 Thomas Fitzsimmons - 0:2.3.0-6jpp_2fc.2 - Bump release number. chkconfig-1.3.26-1 ------------------ * Thu Feb 02 2006 Bill Nottingham 1.3.26-1 - add support for resetting priorities without on/off status (#178864) * Wed Nov 30 2005 Bill Nottingham 1.3.25-1 - return an error if changing services fails (#150235) * Fri Nov 18 2005 Bill Nottingham 1.3.24-1 - when removing alternatives links, check to make sure they're actually links (#173685) dovecot-1.0-0.beta2.3 --------------------- * Thu Feb 02 2006 Petr Rockai - 1.0-0.beta2.3 - change the compiled-in defaults and adjust the default's configfile commented-out example settings to match compiled-in defaults, instead of changing the defaults only in the configfile, as per #179432 - fix #179574 by providing a default uidl_format for pop3 - half-fix #179620 by having plaintext auth enabled by default... this needs more thinking (which one we really want) and documentation either way eclipse-1:3.1.2-1jpp_1fc ------------------------ * Tue Jan 31 2006 Andrew Overholt 3.1.2-1jpp_1fc - 3.1.2. - Remove unnecessary patches. * Tue Jan 31 2006 Karsten Hopp - BuildRequire: unzip flex-2.5.4a-37 -------------- * Thu Feb 02 2006 Petr Machata 2.5.4a-37 - adding `make bigcheck' into build process. Refreshing initscan.c to make this possible. fontconfig-2.3.93.cvs20060131-2 ------------------------------- * Thu Feb 02 2006 Matthias Clasen - 2.3.93.cvs20060131-2 - Accumulated patches gcc-4.1.0-0.20 -------------- * Wed Feb 01 2006 Jakub Jelinek 4.1.0-0.20 - merge from gomp-20050808-branch (up to -r110392) - fix PR c++/25874 (Diego Novillo) glibc-2.3.90-34 --------------- * Thu Feb 02 2006 Jakub Jelinek 2.3.90-34 - fix with C++ and -mlong-double-64 (#179742) - add nexttowardl redirect for -mlong-double-64 * Thu Feb 02 2006 Jakub Jelinek 2.3.90-33 - update from CVS - long double support fixes * Wed Feb 01 2006 Jakub Jelinek 2.3.90-32 - update from CVS - 128-bit long double fixes for ppc{,64}, s390{,x} and sparc{,v9}, alpha 128-bit long double support - add inotify syscall numbers to the override headers (#179366) gnu-crypto-0:2.1.0-1jpp_1fc --------------------------- * Thu Feb 02 2006 Thomas Fitzsimmons - 0:2.1.0-1jpp_1fc - Import GNU Crypto 2.1.0. - Remove gnu-crypto-jce-jdk1.4 and gnu-crypto-sasl-jdk1.4 packages. groff-1.18.1.1-9 ---------------- * Thu Feb 02 2006 Miroslav Lichvar - 1.18.1.1-9 - remove gxditview from groff package (#179684) - remove obsolete "--enable-japanese" configure option gstreamer-plugins-base-0.10.2-2 ------------------------------- * Thu Feb 02 2006 Warren Togami - 0.10.2-2 - buildreq cdparanoia-devel (#179034 thias) gtk2-2.8.11-3 ------------- * Fri Feb 03 2006 Matthias Clasen 2.8.11-3 - Avoid a slowpath in XRender * Fri Jan 27 2006 Matthias Clasen 2.8.11-1 - Update to 2.8.11 * Thu Jan 19 2006 Christopher Aillon 2.8.10-4 - Use Unicode character 2022 for the default invisible character initscripts-8.25-1 ------------------ * Thu Feb 02 2006 Bill Nottingham 8.25-1 - ifup: don't run the arping check if the address is already on the device iptables-1.3.5-1 ---------------- * Thu Feb 02 2006 Thomas Woerner 1.3.5-1 - new version 1.3.5 - fixed init script to set policy for raw tables, too (#179094) java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_73rh ------------------------------------------ * Thu Feb 02 2006 Thomas Fitzsimmons - 0:1.4.2.0-40jpp_73rh - Adjust Jessie and GNU Crypto version requirements. - Uncomment ifnarch ia64 sections. * Thu Feb 02 2006 Thomas Fitzsimmons - 0:1.4.2.0-40jpp_71rh - Obsolete gnu-crypto-sasl-jdk1.4 and gnu-crypto-jce-jdk1.4 regardless of versions. * Thu Feb 02 2006 Thomas Fitzsimmons - 0:1.4.2.0-40jpp_70rh - Remove all ifnarch ia64 sections. jessie-0:1.0.1-1 ---------------- * Thu Feb 02 2006 Thomas Fitzsimmons - 0:1.0.1-1 - Revert back to 1.0.1 sources. * Thu Feb 02 2006 Thomas Fitzsimmons - 0:1.0.1-2 - Revert to 1.0.0 sources. * Thu Feb 02 2006 Thomas Fitzsimmons - 0:1.0.1-1 - Import Jessie 1.0.1. - Require java-sasl instead of gnu-crypto-sasl-jdk1.4 and jce instead of gnu-crypto-jce-jdk1.4 >= 0:2.0.1-1jpp_2fc. junit-0:3.8.1-3jpp_7fc ---------------------- * Thu Feb 02 2006 Archit Shah 0:3.8.1-3jpp_7fc - added dependencies on coreutils kde-i18n-1:3.5.1-1 ------------------ * Wed Feb 01 2006 Than Ngo 1:3.5.1-1 - 3.5.1 kdelibs-6:3.5.1-2 ----------------- * Thu Feb 02 2006 Than Ngo 6:3.5.1-2 - add Obsolete: kdelibs-docs kdemultimedia-6:3.5.1-1 ----------------------- * Thu Feb 02 2006 Than Ngo 6:3.5.1-1 - 3.5.1 kdepim-6:3.5.1-1 ---------------- * Thu Feb 02 2006 Than Ngo 6:3.5.1-1 - update to 3.5.1 - get rid of kdepim-3.5.0-kmail-113730.patch, which included in new upstream kernel-2.6.15-1.1898_FC5 ------------------------ * Thu Feb 02 2006 Dave Jones - 2.6.16rc1-git6 - enable the periodic slab debugger again. * Wed Feb 01 2006 Dave Jones - Woo, 2.6.16rc1-git5 (at last) - Enable exec* checking except for execmod for ppc32 and ia64 (#178747) - Disable a bunch of drivers for SBC's that won't run Fedora. - Reenable building of firmware for QLogic HBA's. - Add a bunch of missing newlines & the like to module init's. - Fix up broken DVB kobject use. - Fixed an oops in the stradis driver initialisation. - Happy Birthday to "The Yellow Dart". * Tue Jan 31 2006 Dave Jones < - Remove prereq on hardlink, making hardlinking of -devel packages optional - Further improvements to the 'dont want to hardlink' case. Now checks for HARDLINK="no" in /etc/sysconfig/kernel kexec-tools-1.101-7.1 --------------------- * Thu Feb 02 2006 Thomas Graf - 1.101-7.1 - Add patch to enable the kdump binary for x86_64 * Wed Feb 01 2006 Thomas Graf - New kdump patch to support s390 arch + various fixes - Include kdump in x86_64 builds libsemanage-1.5.20-1 -------------------- * Thu Feb 02 2006 Dan Walsh 1.5.20-1 - Upgrade to latest from NSA * Merged clone record on set_con patch from Ivan Gyurdiev. libsepol-1.11.12-1 ------------------ * Thu Feb 02 2006 Dan Walsh 1.11.12-1 - Upgrade to latest from NSA * Merged assertion copying bugfix from Joshua Brindle. * Merged sepol_av_to_string patch from Joshua Brindle. * Merged clone record on set_con patch from Ivan Gyurdiev. m17n-lib-1.3.1-1 ---------------- * Thu Feb 02 2006 Jens Petersen - 1.3.1-1 - update to 1.3.1 release - rename use_otf and use_anthy macros to with_gui and with_examples - build --with-gui=no and replace m17n-lib-1.2.0-core-libs-only.patch with m17n-lib-no-gui-headers.patch and m17n-lib-nobuild-examples.patch make-1:3.80-10 -------------- * Thu Feb 02 2006 Petr Machata 3.80-10 - H.J. Lu caught a typo in the patch and provided a new one. (#175376) man-1.6c-1 ---------- * Thu Feb 02 2006 Florian La Roche - 1.6c * Tue Dec 13 2005 Ivana Varekova 1.6b-2 - makewhatis change - add info about packages (bug 175595) * Fri Dec 09 2005 Jesse Keating - rebuilt net-snmp-5.3-4 -------------- * Thu Feb 02 2006 Radek Vok??l 5.3-4 - fix crash on s390x and ppc64 nmap-2:4.00-1 ------------- * Thu Feb 02 2006 Harald Hoyer - 2:4.00-1 - version 4.00 openmotif-2.3.0-0.1.9 --------------------- * Thu Feb 02 2006 Thomas Woerner 2.3.0-0.1.9 - new CVS version 2006-02-02 - fixed CVE-2005-3964: libUil buffer overflows (#174814) - fixed XmList out of bound accesses (#167701) - fixed pasting into TextField (#179549) policycoreutils-1.29.18-1 ------------------------- * Thu Feb 02 2006 Dan Walsh 1.29.18-1 - Update from upstream * Merged clone record on set_con patch from Ivan Gyurdiev. system-config-nfs-1.3.18-1 -------------------------- * Thu Feb 02 2006 Nils Philippsen 1.3.18 - don't complain when trying to edit a share (#179687) - handle wildcards in warning messages for duplicates * Wed Feb 01 2006 Nils Philippsen 1.3.17 - reset properties dialog before being shown for the first time system-config-samba-1.2.32-1 ---------------------------- * Thu Feb 02 2006 Nils Philippsen - 1.2.32 - bump version * Thu Dec 22 2005 Nils Philippsen - add sr at Latn.po to enable Serbian Latin translation * Fri Oct 14 2005 Nils Philippsen - don't use pam_stack (#170642) systemtap-0.5.4-2 ----------------- * Thu Feb 02 2006 Frank Eigler - 0.5.4-2 - Rebuilt for devel * Wed Feb 01 2006 Frank Ch. Eigler - 0.5.4-1 - PRs 1916, 2205, 2142, 2060, 1379 * Mon Jan 16 2006 Roland McGrath - 0.5.3-1 - Many changes, affected PRs include: 2056, 1144, 1379, 2057, 2060, 1972, 2140, 2148 tcl-8.4.12-3 ------------ * Thu Feb 02 2006 David Cantrell - 8.4.12-3 - Patched syntax errors in configure and tcl.m4 so it works with bash * Thu Feb 02 2006 David Cantrell - 8.4.12-2 - Don't use ksh on ia64 * Thu Feb 02 2006 David Cantrell - 8.4.12-1 - Upgraded to tcl-8.4.12 - Use ksh rather than bash for the configure script (known bug w/ bash-3.1) - Generate HTML docs from source - Add in the Tk source for HTML doc generation tk-8.4.12-1 ----------- * Thu Feb 02 2006 David Cantrell - 8.4.12-1 - Upgraded to tk-8.4.12 tzdata-2006a-1 -------------- * Thu Feb 02 2006 Petr Machata 2006a-1 - Upstream 2006a: - private.h(scheck): changing char* to char const* - Rule changes for Palestine, zone changes for Indiana/US, both changes for Canada. - Many related doc changes. - Naming scheme in spec file doesn't use %{name}, but tzdata. xen-3.0-0.20060130.fc5.3 ------------------------ * Thu Feb 02 2006 Bill Nottingham 3.0-0.20060130.fc5.3 - disable iptables/ip6tables/arptables on bridging when bringing up a Xen bridge. If complicated filtering is needed that uses this, custom firewalls will be needed. (#177794) * Tue Jan 31 2006 Bill Nottingham 3.0-0.20060130.fc5.2 - use the default network device, don't hardcode eth0 * Tue Jan 31 2006 - 3.0-0.20060130.fc5.1 - Add xenguest-install.py in /usr/sbin xerces-j2-0:2.6.2-6jpp_3fc -------------------------- * Thu Feb 02 2006 Archit Shah 0:2.6.2-6jpp_3fc - build xerces without using native code * Mon Jan 09 2006 Archit Shah 0:2.6.2-6jpp_2fc - rebuilt for new gcj xorg-x11-drv-acecad-1.0.0.5-1 ----------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-acecad to version 1.0.0.5 from X11R7.0 xorg-x11-drv-aiptek-1.0.0.5-1 ----------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-aiptek to version 1.0.0.5 from X11R7.0 xorg-x11-drv-apm-1.0.1.5-1 -------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.1.5-1 - Updated xorg-x11-drv-apm to version 1.0.1.5 from X11R7.0 - Added apm.xinf videoalias file. xorg-x11-drv-ark-0.5.0.5-1 -------------------------- * Wed Jan 18 2006 Mike A. Harris 0.5.0.5-1 - Updated xorg-x11-drv-ark to version 0.5.0.5 from X11R7.0 xorg-x11-drv-ati-6.5.7.3-1 -------------------------- * Wed Jan 18 2006 Mike A. Harris 6.5.7.3-1 - Updated xorg-x11-drv-ati to version 6.5.7.3 from X11R7.0 - Added ati.xinf videoalias file for hardware autodetection. xorg-x11-drv-calcomp-1.0.0.5-1 ------------------------------ * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-calcomp to version 1.0.0.5 from X11R7.0 xorg-x11-drv-chips-1.0.1.3-1 ---------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.1.3-1 - Updated xorg-x11-drv-chips to version 1.0.1.3 from X11R7.0 xorg-x11-drv-cirrus-1.0.0.5-1 ----------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-cirrus to version 1.0.0.5 from X11R7.0 xorg-x11-drv-citron-2.1.1.5-1 ----------------------------- * Wed Jan 18 2006 Mike A. Harris 2.1.1.5-1 - Updated xorg-x11-drv-citron to version 2.1.1.5 from X11R7.0 xorg-x11-drv-cyrix-1.0.0.5-1 ---------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-cyrix to version 1.0.0.5 from X11R7.0 xorg-x11-drv-digitaledge-1.0.1.3-1 ---------------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.1.3-1 - Updated xorg-x11-drv-digitaledge to version 1.0.1.3 from X11R7.0 xorg-x11-drv-dmc-1.0.0.5-1 -------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-dmc to version 1.0.0.5 from X11R7.0 xorg-x11-drv-dynapro-1.0.0.5-1 ------------------------------ * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-dynapro to version 1.0.0.5 from X11R7.0 xorg-x11-drv-elo2300-1.0.0.5-1 ------------------------------ * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-elo2300 to version 1.0.0.5 from X11R7.0 xorg-x11-drv-elographics-1.0.0.5-1 ---------------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-elographics to version 1.0.0.5 from X11R7.0 xorg-x11-drv-evdev-1.0.0.5-1 ---------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-evdev to version 1.0.0.5 from X11R7.0 xorg-x11-drv-fbdev-0.1.0.5-1 ---------------------------- * Wed Jan 18 2006 Mike A. Harris 0.1.0.5-1 - Updated xorg-x11-drv-fbdev to version 0.1.0.5 from X11R7.0 xorg-x11-drv-fpit-1.0.0.5-1 --------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-fpit to version 1.0.0.5 from X11R7.0 xorg-x11-drv-hyperpen-1.0.0.5-1 ------------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-hyperpen to version 1.0.0.5 from X11R7.0 xorg-x11-drv-i128-1.1.0.5-1 --------------------------- * Wed Jan 18 2006 Mike A. Harris 1.1.0.5-1 - Updated xorg-x11-drv-i128 to version 1.1.0.5 from X11R7.0 xorg-x11-drv-jamstudio-1.0.0.5-1 -------------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-jamstudio to version 1.0.0.5 from X11R7.0 xorg-x11-drv-joystick-1.0.0.5-1 ------------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-joystick to version 1.0.0.5 from X11R7.0 xorg-x11-drv-keyboard-1.0.1.3-1 ------------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.1.3-1 - Updated xorg-x11-drv-keyboard to version 1.0.1.3 from X11R7.0 - Added alpha/sparc/sparc64 to ExclusiveArch list (#176590) xorg-x11-drv-magellan-1.0.0.5-1 ------------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-magellan to version 1.0.0.5 from X11R7.0 xorg-x11-drv-magictouch-1.0.0.5-1 --------------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-magictouch to version 1.0.0.5 from X11R7.0 xorg-x11-drv-microtouch-1.0.0.5-1 --------------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-microtouch to version 1.0.0.5 from X11R7.0 xorg-x11-drv-mouse-1.0.3.1-1 ---------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.3.1-1 - Updated xorg-x11-drv-mouse to version 1.0.3.1 from X11R7.0 - Rename temporary name of mouse manpage, to close (#178744) xorg-x11-drv-mutouch-1.0.0.5-1 ------------------------------ * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-mutouch to version 1.0.0.5 from X11R7.0 xorg-x11-drv-palmax-1.0.0.5-1 ----------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-palmax to version 1.0.0.5 from X11R7.0 xorg-x11-drv-penmount-1.0.0.5-1 ------------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-penmount to version 1.0.0.5 from X11R7.0 - Removed 'x' suffix from manpage dirs to match RC4 upstream. xorg-x11-drv-siliconmotion-1.3.1.5-1 ------------------------------------ * Wed Jan 18 2006 Mike A. Harris 1.3.1.5-1 - Updated xorg-x11-drv-siliconmotion to version 1.3.1.5 from X11R7.0 xorg-x11-drv-sisusb-0.7.1.3-1 ----------------------------- * Wed Jan 18 2006 Mike A. Harris 0.7.1.3-1 - Updated xorg-x11-drv-sisusb to version 0.7.1.3 from X11R7.0 - Removed 'x' suffix from manpage dirs to match RC4 upstream. xorg-x11-drv-spaceorb-1.0.0.5-1 ------------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-spaceorb to version 1.0.0.5 from X11R7.0 xorg-x11-drv-summa-1.0.0.5-1 ---------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-summa to version 1.0.0.5 from X11R7.0 xorg-x11-drv-ur98-1.0.0.5-1 --------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-ur98 to version 1.0.0.5 from X11R7.0 xorg-x11-drv-void-1.0.0.5-1 --------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-void to version 1.0.0.5 from X11R7.0 Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 Broken deps for ia64 ---------------------------------------------------------- gnome-volume-manager - 1.5.11-1.ia64 requires kernel >= 0:2.6 iscsi-initiator-utils - 5.0.5.476-0.ia64 requires kernel pcmciautils - 011-1.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 rgmanager - 1.9.31-3.ia64 requires ccs systemtap - 0.5.4-2.ia64 requires kernel >= 0:2.6.9-11 Broken deps for ppc ---------------------------------------------------------- ccs-devel - 1.0.2-3.1.ppc requires ccs = 0:1.0.2-3.1 gulm - 1.0.4-2.FC5.1.ppc requires ccs Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.4-2.s390 requires kernel >= 0:2.6.9-11 Broken deps for s390x ---------------------------------------------------------- libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) systemtap - 0.5.4-2.s390x requires kernel >= 0:2.6.9-11 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 From gazzerh at gmail.com Fri Feb 3 15:59:07 2006 From: gazzerh at gmail.com (Garry Harthill) Date: Fri, 3 Feb 2006 15:59:07 +0000 Subject: rawhide report: 20060203 changes In-Reply-To: <200602031549.k13FnTaM006152@porkchop.devel.redhat.com> References: <200602031549.k13FnTaM006152@porkchop.devel.redhat.com> Message-ID: <1fcc9e320602030759n139d4860x@mail.gmail.com> On 03/02/06, Build System wrote: > New package jakarta-commons-discovery > Jakarta Commons Discovery > > > > Updated Packages: > > GConf2-2.13.5-3 > --------------- > * Thu Feb 02 2006 Christopher Aillon 2.13.5-3 > - Use the correct patch ;-) > > anaconda-10.91.13-1 > ------------------- > * Thu Feb 02 2006 Jeremy Katz - 10.91.13-1 > - Speed up timezone screen (clumens) > - Make kickstart interactive mode work (clumens) > - Fix package selection screen (clumens) > - Add sqlite to traceonly to help http/ftp memory usage > - Write out repo config (pnasrat) > - Fix colors on boot splashes (#178033) > - Select lang groups before going to the screen (#178673) > - Clean up handling of grub vs no boot loader (#159658) > > bsf-0:2.3.0-6jpp_2fc.2 > ---------------------- > * Thu Feb 02 2006 Thomas Fitzsimmons - 0:2.3.0-6jpp_2fc.2 > - Bump release number. > > chkconfig-1.3.26-1 > ------------------ > * Thu Feb 02 2006 Bill Nottingham 1.3.26-1 > - add support for resetting priorities without on/off status (#178864) > > * Wed Nov 30 2005 Bill Nottingham 1.3.25-1 > - return an error if changing services fails (#150235) > > * Fri Nov 18 2005 Bill Nottingham 1.3.24-1 > - when removing alternatives links, check to make sure they're > actually links (#173685) > > dovecot-1.0-0.beta2.3 > --------------------- > * Thu Feb 02 2006 Petr Rockai - 1.0-0.beta2.3 > - change the compiled-in defaults and adjust the default's configfile > commented-out example settings to match compiled-in defaults, > instead of changing the defaults only in the configfile, as per #179432 > - fix #179574 by providing a default uidl_format for pop3 > - half-fix #179620 by having plaintext auth enabled by default... this > needs more thinking (which one we really want) and documentation > either way > > eclipse-1:3.1.2-1jpp_1fc > ------------------------ > * Tue Jan 31 2006 Andrew Overholt 3.1.2-1jpp_1fc > - 3.1.2. > - Remove unnecessary patches. > > * Tue Jan 31 2006 Karsten Hopp > - BuildRequire: unzip > > flex-2.5.4a-37 > -------------- > * Thu Feb 02 2006 Petr Machata 2.5.4a-37 > - adding `make bigcheck' into build process. Refreshing initscan.c to > make this possible. > > fontconfig-2.3.93.cvs20060131-2 > ------------------------------- > * Thu Feb 02 2006 Matthias Clasen - 2.3.93.cvs20060131-2 > - Accumulated patches > > gcc-4.1.0-0.20 > -------------- > * Wed Feb 01 2006 Jakub Jelinek 4.1.0-0.20 > - merge from gomp-20050808-branch (up to -r110392) > - fix PR c++/25874 (Diego Novillo) > > glibc-2.3.90-34 > --------------- > * Thu Feb 02 2006 Jakub Jelinek 2.3.90-34 > - fix with C++ and -mlong-double-64 (#179742) > - add nexttowardl redirect for -mlong-double-64 > > * Thu Feb 02 2006 Jakub Jelinek 2.3.90-33 > - update from CVS > - long double support fixes > > * Wed Feb 01 2006 Jakub Jelinek 2.3.90-32 > - update from CVS > - 128-bit long double fixes for ppc{,64}, s390{,x} and sparc{,v9}, > alpha 128-bit long double support > - add inotify syscall numbers to the override headers > (#179366) > > gnu-crypto-0:2.1.0-1jpp_1fc > --------------------------- > * Thu Feb 02 2006 Thomas Fitzsimmons - 0:2.1.0-1jpp_1fc > - Import GNU Crypto 2.1.0. > - Remove gnu-crypto-jce-jdk1.4 and gnu-crypto-sasl-jdk1.4 packages. > > groff-1.18.1.1-9 > ---------------- > * Thu Feb 02 2006 Miroslav Lichvar - 1.18.1.1-9 > - remove gxditview from groff package (#179684) > - remove obsolete "--enable-japanese" configure option > > gstreamer-plugins-base-0.10.2-2 > ------------------------------- > * Thu Feb 02 2006 Warren Togami - 0.10.2-2 > - buildreq cdparanoia-devel (#179034 thias) > > gtk2-2.8.11-3 > ------------- > * Fri Feb 03 2006 Matthias Clasen 2.8.11-3 > - Avoid a slowpath in XRender > > * Fri Jan 27 2006 Matthias Clasen 2.8.11-1 > - Update to 2.8.11 > > * Thu Jan 19 2006 Christopher Aillon 2.8.10-4 > - Use Unicode character 2022 for the default invisible character > > initscripts-8.25-1 > ------------------ > * Thu Feb 02 2006 Bill Nottingham 8.25-1 > - ifup: don't run the arping check if the address is already on the device > > iptables-1.3.5-1 > ---------------- > * Thu Feb 02 2006 Thomas Woerner 1.3.5-1 > - new version 1.3.5 > - fixed init script to set policy for raw tables, too (#179094) > > java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_73rh > ------------------------------------------ > * Thu Feb 02 2006 Thomas Fitzsimmons - 0:1.4.2.0-40jpp_73rh > - Adjust Jessie and GNU Crypto version requirements. > - Uncomment ifnarch ia64 sections. > > * Thu Feb 02 2006 Thomas Fitzsimmons - 0:1.4.2.0-40jpp_71rh > - Obsolete gnu-crypto-sasl-jdk1.4 and gnu-crypto-jce-jdk1.4 regardless of versions. > > * Thu Feb 02 2006 Thomas Fitzsimmons - 0:1.4.2.0-40jpp_70rh > - Remove all ifnarch ia64 sections. > > jessie-0:1.0.1-1 > ---------------- > * Thu Feb 02 2006 Thomas Fitzsimmons - 0:1.0.1-1 > - Revert back to 1.0.1 sources. > > * Thu Feb 02 2006 Thomas Fitzsimmons - 0:1.0.1-2 > - Revert to 1.0.0 sources. > > * Thu Feb 02 2006 Thomas Fitzsimmons - 0:1.0.1-1 > - Import Jessie 1.0.1. > - Require java-sasl instead of gnu-crypto-sasl-jdk1.4 and jce instead > of gnu-crypto-jce-jdk1.4 >= 0:2.0.1-1jpp_2fc. > > junit-0:3.8.1-3jpp_7fc > ---------------------- > * Thu Feb 02 2006 Archit Shah 0:3.8.1-3jpp_7fc > - added dependencies on coreutils > > kde-i18n-1:3.5.1-1 > ------------------ > * Wed Feb 01 2006 Than Ngo 1:3.5.1-1 > - 3.5.1 > > kdelibs-6:3.5.1-2 > ----------------- > * Thu Feb 02 2006 Than Ngo 6:3.5.1-2 > - add Obsolete: kdelibs-docs > > kdemultimedia-6:3.5.1-1 > ----------------------- > * Thu Feb 02 2006 Than Ngo 6:3.5.1-1 > - 3.5.1 > > kdepim-6:3.5.1-1 > ---------------- > * Thu Feb 02 2006 Than Ngo 6:3.5.1-1 > - update to 3.5.1 > - get rid of kdepim-3.5.0-kmail-113730.patch, which included in new upstream > > kernel-2.6.15-1.1898_FC5 > ------------------------ > * Thu Feb 02 2006 Dave Jones > - 2.6.16rc1-git6 > - enable the periodic slab debugger again. > > * Wed Feb 01 2006 Dave Jones > - Woo, 2.6.16rc1-git5 (at last) > - Enable exec* checking except for execmod for ppc32 and ia64 (#178747) > - Disable a bunch of drivers for SBC's that won't run Fedora. > - Reenable building of firmware for QLogic HBA's. > - Add a bunch of missing newlines & the like to module init's. > - Fix up broken DVB kobject use. > - Fixed an oops in the stradis driver initialisation. > - Happy Birthday to "The Yellow Dart". > > * Tue Jan 31 2006 Dave Jones < > - Remove prereq on hardlink, making hardlinking of -devel packages optional > - Further improvements to the 'dont want to hardlink' case. > Now checks for HARDLINK="no" in /etc/sysconfig/kernel > > kexec-tools-1.101-7.1 > --------------------- > * Thu Feb 02 2006 Thomas Graf - 1.101-7.1 > - Add patch to enable the kdump binary for x86_64 > > * Wed Feb 01 2006 Thomas Graf > - New kdump patch to support s390 arch + various fixes > - Include kdump in x86_64 builds > > libsemanage-1.5.20-1 > -------------------- > * Thu Feb 02 2006 Dan Walsh 1.5.20-1 > - Upgrade to latest from NSA > * Merged clone record on set_con patch from Ivan Gyurdiev. > > libsepol-1.11.12-1 > ------------------ > * Thu Feb 02 2006 Dan Walsh 1.11.12-1 > - Upgrade to latest from NSA > * Merged assertion copying bugfix from Joshua Brindle. > * Merged sepol_av_to_string patch from Joshua Brindle. > * Merged clone record on set_con patch from Ivan Gyurdiev. > > m17n-lib-1.3.1-1 > ---------------- > * Thu Feb 02 2006 Jens Petersen - 1.3.1-1 > - update to 1.3.1 release > - rename use_otf and use_anthy macros to with_gui and with_examples > - build --with-gui=no and replace m17n-lib-1.2.0-core-libs-only.patch > with m17n-lib-no-gui-headers.patch and m17n-lib-nobuild-examples.patch > > make-1:3.80-10 > -------------- > * Thu Feb 02 2006 Petr Machata 3.80-10 > - H.J. Lu caught a typo in the patch and provided a new one. (#175376) > > man-1.6c-1 > ---------- > * Thu Feb 02 2006 Florian La Roche > - 1.6c > > * Tue Dec 13 2005 Ivana Varekova 1.6b-2 > - makewhatis change - add info about packages (bug 175595) > > * Fri Dec 09 2005 Jesse Keating > - rebuilt > > net-snmp-5.3-4 > -------------- > * Thu Feb 02 2006 Radek Vok?l 5.3-4 > - fix crash on s390x and ppc64 > > nmap-2:4.00-1 > ------------- > * Thu Feb 02 2006 Harald Hoyer - 2:4.00-1 > - version 4.00 > > openmotif-2.3.0-0.1.9 > --------------------- > * Thu Feb 02 2006 Thomas Woerner 2.3.0-0.1.9 > - new CVS version 2006-02-02 > - fixed CVE-2005-3964: libUil buffer overflows (#174814) > - fixed XmList out of bound accesses (#167701) > - fixed pasting into TextField (#179549) > > policycoreutils-1.29.18-1 > ------------------------- > * Thu Feb 02 2006 Dan Walsh 1.29.18-1 > - Update from upstream > * Merged clone record on set_con patch from Ivan Gyurdiev. > > system-config-nfs-1.3.18-1 > -------------------------- > * Thu Feb 02 2006 Nils Philippsen 1.3.18 > - don't complain when trying to edit a share (#179687) > - handle wildcards in warning messages for duplicates > > * Wed Feb 01 2006 Nils Philippsen 1.3.17 > - reset properties dialog before being shown for the first time > > system-config-samba-1.2.32-1 > ---------------------------- > * Thu Feb 02 2006 Nils Philippsen - 1.2.32 > - bump version > > * Thu Dec 22 2005 Nils Philippsen > - add sr at Latn.po to enable Serbian Latin translation > > * Fri Oct 14 2005 Nils Philippsen > - don't use pam_stack (#170642) > > systemtap-0.5.4-2 > ----------------- > * Thu Feb 02 2006 Frank Eigler - 0.5.4-2 > - Rebuilt for devel > > * Wed Feb 01 2006 Frank Ch. Eigler - 0.5.4-1 > - PRs 1916, 2205, 2142, 2060, 1379 > > * Mon Jan 16 2006 Roland McGrath - 0.5.3-1 > - Many changes, affected PRs include: 2056, 1144, 1379, 2057, > 2060, 1972, 2140, 2148 > > tcl-8.4.12-3 > ------------ > * Thu Feb 02 2006 David Cantrell - 8.4.12-3 > - Patched syntax errors in configure and tcl.m4 so it works with bash > > * Thu Feb 02 2006 David Cantrell - 8.4.12-2 > - Don't use ksh on ia64 > > * Thu Feb 02 2006 David Cantrell - 8.4.12-1 > - Upgraded to tcl-8.4.12 > - Use ksh rather than bash for the configure script (known bug w/ bash-3.1) > - Generate HTML docs from source > - Add in the Tk source for HTML doc generation > > tk-8.4.12-1 > ----------- > * Thu Feb 02 2006 David Cantrell - 8.4.12-1 > - Upgraded to tk-8.4.12 > > tzdata-2006a-1 > -------------- > * Thu Feb 02 2006 Petr Machata 2006a-1 > - Upstream 2006a: > - private.h(scheck): changing char* to char const* > - Rule changes for Palestine, zone changes for Indiana/US, both > changes for Canada. > - Many related doc changes. > - Naming scheme in spec file doesn't use %{name}, but tzdata. > > xen-3.0-0.20060130.fc5.3 > ------------------------ > * Thu Feb 02 2006 Bill Nottingham 3.0-0.20060130.fc5.3 > - disable iptables/ip6tables/arptables on bridging when bringing up a > Xen bridge. If complicated filtering is needed that uses this, custom > firewalls will be needed. (#177794) > > * Tue Jan 31 2006 Bill Nottingham 3.0-0.20060130.fc5.2 > - use the default network device, don't hardcode eth0 > > * Tue Jan 31 2006 - 3.0-0.20060130.fc5.1 > - Add xenguest-install.py in /usr/sbin > > xerces-j2-0:2.6.2-6jpp_3fc > -------------------------- > * Thu Feb 02 2006 Archit Shah 0:2.6.2-6jpp_3fc > - build xerces without using native code > > * Mon Jan 09 2006 Archit Shah 0:2.6.2-6jpp_2fc > - rebuilt for new gcj > > xorg-x11-drv-acecad-1.0.0.5-1 > ----------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 > - Updated xorg-x11-drv-acecad to version 1.0.0.5 from X11R7.0 > > xorg-x11-drv-aiptek-1.0.0.5-1 > ----------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 > - Updated xorg-x11-drv-aiptek to version 1.0.0.5 from X11R7.0 > > xorg-x11-drv-apm-1.0.1.5-1 > -------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.0.1.5-1 > - Updated xorg-x11-drv-apm to version 1.0.1.5 from X11R7.0 > - Added apm.xinf videoalias file. > > xorg-x11-drv-ark-0.5.0.5-1 > -------------------------- > * Wed Jan 18 2006 Mike A. Harris 0.5.0.5-1 > - Updated xorg-x11-drv-ark to version 0.5.0.5 from X11R7.0 > > xorg-x11-drv-ati-6.5.7.3-1 > -------------------------- > * Wed Jan 18 2006 Mike A. Harris 6.5.7.3-1 > - Updated xorg-x11-drv-ati to version 6.5.7.3 from X11R7.0 > - Added ati.xinf videoalias file for hardware autodetection. > > xorg-x11-drv-calcomp-1.0.0.5-1 > ------------------------------ > * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 > - Updated xorg-x11-drv-calcomp to version 1.0.0.5 from X11R7.0 > > xorg-x11-drv-chips-1.0.1.3-1 > ---------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.0.1.3-1 > - Updated xorg-x11-drv-chips to version 1.0.1.3 from X11R7.0 > > xorg-x11-drv-cirrus-1.0.0.5-1 > ----------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 > - Updated xorg-x11-drv-cirrus to version 1.0.0.5 from X11R7.0 > > xorg-x11-drv-citron-2.1.1.5-1 > ----------------------------- > * Wed Jan 18 2006 Mike A. Harris 2.1.1.5-1 > - Updated xorg-x11-drv-citron to version 2.1.1.5 from X11R7.0 > > xorg-x11-drv-cyrix-1.0.0.5-1 > ---------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 > - Updated xorg-x11-drv-cyrix to version 1.0.0.5 from X11R7.0 > > xorg-x11-drv-digitaledge-1.0.1.3-1 > ---------------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.0.1.3-1 > - Updated xorg-x11-drv-digitaledge to version 1.0.1.3 from X11R7.0 > > xorg-x11-drv-dmc-1.0.0.5-1 > -------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 > - Updated xorg-x11-drv-dmc to version 1.0.0.5 from X11R7.0 > > xorg-x11-drv-dynapro-1.0.0.5-1 > ------------------------------ > * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 > - Updated xorg-x11-drv-dynapro to version 1.0.0.5 from X11R7.0 > > xorg-x11-drv-elo2300-1.0.0.5-1 > ------------------------------ > * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 > - Updated xorg-x11-drv-elo2300 to version 1.0.0.5 from X11R7.0 > > xorg-x11-drv-elographics-1.0.0.5-1 > ---------------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 > - Updated xorg-x11-drv-elographics to version 1.0.0.5 from X11R7.0 > > xorg-x11-drv-evdev-1.0.0.5-1 > ---------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 > - Updated xorg-x11-drv-evdev to version 1.0.0.5 from X11R7.0 > > xorg-x11-drv-fbdev-0.1.0.5-1 > ---------------------------- > * Wed Jan 18 2006 Mike A. Harris 0.1.0.5-1 > - Updated xorg-x11-drv-fbdev to version 0.1.0.5 from X11R7.0 > > xorg-x11-drv-fpit-1.0.0.5-1 > --------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 > - Updated xorg-x11-drv-fpit to version 1.0.0.5 from X11R7.0 > > xorg-x11-drv-hyperpen-1.0.0.5-1 > ------------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 > - Updated xorg-x11-drv-hyperpen to version 1.0.0.5 from X11R7.0 > > xorg-x11-drv-i128-1.1.0.5-1 > --------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.1.0.5-1 > - Updated xorg-x11-drv-i128 to version 1.1.0.5 from X11R7.0 > > xorg-x11-drv-jamstudio-1.0.0.5-1 > -------------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 > - Updated xorg-x11-drv-jamstudio to version 1.0.0.5 from X11R7.0 > > xorg-x11-drv-joystick-1.0.0.5-1 > ------------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 > - Updated xorg-x11-drv-joystick to version 1.0.0.5 from X11R7.0 > > xorg-x11-drv-keyboard-1.0.1.3-1 > ------------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.0.1.3-1 > - Updated xorg-x11-drv-keyboard to version 1.0.1.3 from X11R7.0 > - Added alpha/sparc/sparc64 to ExclusiveArch list (#176590) > > xorg-x11-drv-magellan-1.0.0.5-1 > ------------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 > - Updated xorg-x11-drv-magellan to version 1.0.0.5 from X11R7.0 > > xorg-x11-drv-magictouch-1.0.0.5-1 > --------------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 > - Updated xorg-x11-drv-magictouch to version 1.0.0.5 from X11R7.0 > > xorg-x11-drv-microtouch-1.0.0.5-1 > --------------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 > - Updated xorg-x11-drv-microtouch to version 1.0.0.5 from X11R7.0 > > xorg-x11-drv-mouse-1.0.3.1-1 > ---------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.0.3.1-1 > - Updated xorg-x11-drv-mouse to version 1.0.3.1 from X11R7.0 > - Rename temporary name of mouse manpage, to close (#178744) > > xorg-x11-drv-mutouch-1.0.0.5-1 > ------------------------------ > * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 > - Updated xorg-x11-drv-mutouch to version 1.0.0.5 from X11R7.0 > > xorg-x11-drv-palmax-1.0.0.5-1 > ----------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 > - Updated xorg-x11-drv-palmax to version 1.0.0.5 from X11R7.0 > > xorg-x11-drv-penmount-1.0.0.5-1 > ------------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 > - Updated xorg-x11-drv-penmount to version 1.0.0.5 from X11R7.0 > - Removed 'x' suffix from manpage dirs to match RC4 upstream. > > xorg-x11-drv-siliconmotion-1.3.1.5-1 > ------------------------------------ > * Wed Jan 18 2006 Mike A. Harris 1.3.1.5-1 > - Updated xorg-x11-drv-siliconmotion to version 1.3.1.5 from X11R7.0 > > xorg-x11-drv-sisusb-0.7.1.3-1 > ----------------------------- > * Wed Jan 18 2006 Mike A. Harris 0.7.1.3-1 > - Updated xorg-x11-drv-sisusb to version 0.7.1.3 from X11R7.0 > - Removed 'x' suffix from manpage dirs to match RC4 upstream. > > xorg-x11-drv-spaceorb-1.0.0.5-1 > ------------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 > - Updated xorg-x11-drv-spaceorb to version 1.0.0.5 from X11R7.0 > > xorg-x11-drv-summa-1.0.0.5-1 > ---------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 > - Updated xorg-x11-drv-summa to version 1.0.0.5 from X11R7.0 > > xorg-x11-drv-ur98-1.0.0.5-1 > --------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 > - Updated xorg-x11-drv-ur98 to version 1.0.0.5 from X11R7.0 > xorg-x11-drv-void-1.0.0.5-1 > --------------------------- > * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 > - Updated xorg-x11-drv-void to version 1.0.0.5 from X11R7.0 > > Broken deps for i386 > ---------------------------------------------------------- > GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 > GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 > GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp > GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 > cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 > cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 > cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp > cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 > dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 > dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 > dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp > dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 > gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 > gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 > gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp > gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 > > > > Broken deps for ia64 > ---------------------------------------------------------- > gnome-volume-manager - 1.5.11-1.ia64 requires kernel >= 0:2.6 > iscsi-initiator-utils - 5.0.5.476-0.ia64 requires kernel > pcmciautils - 011-1.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 > rgmanager - 1.9.31-3.ia64 requires ccs > systemtap - 0.5.4-2.ia64 requires kernel >= 0:2.6.9-11 > > > > Broken deps for ppc > ---------------------------------------------------------- > ccs-devel - 1.0.2-3.1.ppc requires ccs = 0:1.0.2-3.1 > gulm - 1.0.4-2.FC5.1.ppc requires ccs > > > > Broken deps for ppc64 > ---------------------------------------------------------- > cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 > dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 > emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi > gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 > > > > Broken deps for s390 > ---------------------------------------------------------- > systemtap - 0.5.4-2.s390 requires kernel >= 0:2.6.9-11 > > > > Broken deps for s390x > ---------------------------------------------------------- > libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) > libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) > systemtap - 0.5.4-2.s390x requires kernel >= 0:2.6.9-11 > > > > Broken deps for x86_64 > ---------------------------------------------------------- > GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 > GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 > cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 > cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 > dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 > dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 > gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 > gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 Am I blind or is the sqlite update to fix yum missing? Garry From dimi at lattica.com Fri Feb 3 16:05:56 2006 From: dimi at lattica.com (Dimi Paun) Date: Fri, 3 Feb 2006 11:05:56 -0500 Subject: rawhide report: 20060203 changes References: <200602031549.k13FnTaM006152@porkchop.devel.redhat.com> <1fcc9e320602030759n139d4860x@mail.gmail.com> Message-ID: <062101c628db$b9de99c0$b6491b31@td612671> From: "Garry Harthill" [snip too many lines ] > Am I blind or is the sqlite update to fix yum missing? Can we please avoid quoting an inordinate amount of stuff when asking or replying? It is very annoying, and wasteful. Thanks. -- Dimi Paun Lattica, Inc. From emeric.maschino at jouy.inra.fr Fri Feb 3 16:08:17 2006 From: emeric.maschino at jouy.inra.fr (Emeric Maschino) Date: Fri, 03 Feb 2006 17:08:17 +0100 Subject: rawhide report: 20060203 changes In-Reply-To: <1fcc9e320602030759n139d4860x@mail.gmail.com> References: <200602031549.k13FnTaM006152@porkchop.devel.redhat.com> <1fcc9e320602030759n139d4860x@mail.gmail.com> Message-ID: <1138982897.5041.27.camel@localhost.localdomain> > Am I blind or is the sqlite update to fix yum missing? > > Garry If you're referring to the yum memory issue, yesterday's python- sqlite-1.1.6-3 corrected the problem for me. ?meric From caillon at redhat.com Fri Feb 3 16:09:54 2006 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 03 Feb 2006 11:09:54 -0500 Subject: rawhide report: 20060203 changes In-Reply-To: <1fcc9e320602030759n139d4860x@mail.gmail.com> References: <200602031549.k13FnTaM006152@porkchop.devel.redhat.com> <1fcc9e320602030759n139d4860x@mail.gmail.com> Message-ID: <43E38052.8080408@redhat.com> On 02/03/2006 10:59 AM, Garry Harthill wrote: > Am I blind or is the sqlite update to fix yum missing? > > Garry > Ah, now that I've found your question (next time please abridge the text you're replying to, or at the very least post at the top so we can find it), you're looking for the wrong package on the wrong day. This was fixed already yesterday, and by python-sqlite, not sqlite, which was also pointed out several times on this list already. From d.jacobfeuerborn at conversis.de Fri Feb 3 16:15:50 2006 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Fri, 03 Feb 2006 17:15:50 +0100 Subject: Rawhide performance? In-Reply-To: <43E328D6.7010309@mharris.ca> References: <1138835047.3324.91.camel@mentorng.gurulabs.com> <43E1D00F.2040807@pvv.org> <43E328D6.7010309@mharris.ca> Message-ID: <43E381B6.3050405@conversis.de> Mike A. Harris wrote: > Trond Eivind Glomsr?d wrote: >> Dax Kelson wrote: >> >>> I installed rawhide on a beefy desktop computer. >>> >>> AMD FX-55 CPU >>> 2GB RAM >>> 300GB SATA RAID1 (testing out the new dmraid integration) >>> Nvidia 6800GT 256MB video (Qty 2 -- SLI) >>> 1600x1200 resolution >>> >>> I haven't quantified it yet, but desktop GNOME performance seems very >>> sluggish. Many seconds to launch apps. Many seconds for the GNOME panel >>> menu to drop down and populate with icons. In general the lack of >>> performance is bad enough to be very noticeable and annoying. >> >> One trick which improved performance from what you describe to ok for >> me, was rerunning fc-cache - I had a directory of fonts in my home >> directory, and it seemed to parse them every time something started. > > At some point in FC5 development, a fontconfig update seems to have > been rather buggy, and caused performance problems also. I don't > know the details, but the package maintainer and others have alluded > to this, and runtime behaviour was certainly suggestive of it as well. I recompiled the xorg-x11-server package with this patch a couple of minutes ago: https://bugs.freedesktop.org/show_bug.cgi?id=4320#c11 The performance increase on the desktop this bug delivers is quite dramatic. Regards, Dennis From selinux at gmail.com Fri Feb 3 16:17:46 2006 From: selinux at gmail.com (Tom London) Date: Fri, 3 Feb 2006 08:17:46 -0800 Subject: rawhide report: 20060203 changes In-Reply-To: <200602031549.k13FnTaM006152@porkchop.devel.redhat.com> References: <200602031549.k13FnTaM006152@porkchop.devel.redhat.com> Message-ID: <4c4ba1530602030817t70b8a24fi92e172e4f45d4cd3@mail.gmail.com> Get this on 'yum install': Updating : glibc ##################### [ 4/184] Stopping sshd: [ OK ] touch: setting times of `/var/lock/subsys/sshd': Bad address Updating : chkconfig ##################### [ 5/184] Updating : libstdc++ ##################### [ 6/184] Updating : tcl ##################### [ 7/184] Updating : fontconfig ##################### [ 8/184] touch: setting times of `/var/cache/fontconfig/stamp': Bad address Updating : gtk2 ##################### [ 9/184] From dhollis at davehollis.com Fri Feb 3 16:20:22 2006 From: dhollis at davehollis.com (David Hollis) Date: Fri, 03 Feb 2006 11:20:22 -0500 Subject: rawhide report: 20060203 changes In-Reply-To: <1fcc9e320602030759n139d4860x@mail.gmail.com> References: <200602031549.k13FnTaM006152@porkchop.devel.redhat.com> <1fcc9e320602030759n139d4860x@mail.gmail.com> Message-ID: <1138983622.2737.16.camel@dhollis-lnx.sunera.com> On Fri, 2006-02-03 at 15:59 +0000, Garry Harthill wrote: > > Am I blind or is the sqlite update to fix yum missing? > > Garry That was the python-sqlite update yesterday. Took care of the yum-eating-memory-infinitely problem. -- David 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 katzj at redhat.com Fri Feb 3 16:37:40 2006 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 03 Feb 2006 11:37:40 -0500 Subject: rawhide report: 20060202 changes In-Reply-To: <20060203122630.a157a068.petersen@redhat.com> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> <1138896089.15099.6.camel@kloczek01.pracownicy.zie> <20060203122630.a157a068.petersen@redhat.com> Message-ID: <1138984660.2652.5.camel@bree.local.net> On Fri, 2006-02-03 at 12:26 +0900, Jens Petersen wrote: > On Thu, 02 Feb 2006 17:01:29 +0100 > Tomasz K?oczko wrote: > > Instead [of] generat[ing] 41 binary subpackages m17n-db* each with support > > for one language better [to] generate one with correctly used %lang() > > macros in %files list. > > The problem is that most people using m17n only need one or two of > its langs installed at most, but not necessarily the ones for which they > want software translations say (and anyway by default all translations > are installed by default nowadays afaict). If all the input maps in > m17n-db get installed by default, then about 40 languages appear in the > SCIM language selection menu suddenly which is not nice. So if I have a public access terminal and support people running in any of the languages we ship, then it's better that there are 40 languages there? It sounds like you're just trying to work around a poor UI design here. Jeremy From katzj at redhat.com Fri Feb 3 16:37:43 2006 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 03 Feb 2006 11:37:43 -0500 Subject: rawhide report: 20060202 changes In-Reply-To: <20060203130049.b8de9fc7.petersen@redhat.com> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> <1138896089.15099.6.camel@kloczek01.pracownicy.zie> <20060202172433.2a79d274@python2> <20060202164652.GA5019@devserv.devel.redhat.com> <1138915939.15099.34.camel@kloczek01.pracownicy.zie> <20060203130049.b8de9fc7.petersen@redhat.com> Message-ID: <1138984663.2652.7.camel@bree.local.net> On Fri, 2006-02-03 at 13:00 +0900, Jens Petersen wrote: > On Thu, 02 Feb 2006 22:32:19 +0100 > Tomasz K?oczko wrote: > > On first look m17n it is real piece of crap. Why? Because in > > current form it duplicates many things from libc locale database and few > > more things (did I write "duplicates" ? .. correction: it is not second > > copy of locale/encodings description because second sits in XLOCALE > > [1]). > > That is basically why I separated some of the large datafiles to a > separate subpackage (m17n-db-datafiles) so they don't need to be > installed by default. The main m17n-db package manifest is only 86kB. Then what does need it? If nothing needs it, why is it being shipped? Jeremy From katzj at redhat.com Fri Feb 3 16:37:52 2006 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 03 Feb 2006 11:37:52 -0500 Subject: rawhide report: 20060202 changes In-Reply-To: <20060203123627.15f9ce5f.petersen@redhat.com> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> <1138896089.15099.6.camel@kloczek01.pracownicy.zie> <20060202172433.2a79d274@python2> <20060202164652.GA5019@devserv.devel.redhat.com> <20060203123627.15f9ce5f.petersen@redhat.com> Message-ID: <1138984672.2652.8.camel@bree.local.net> On Fri, 2006-02-03 at 12:36 +0900, Jens Petersen wrote: > On Thu, 2 Feb 2006 11:46:52 -0500 > Bill Nottingham wrote: > > I expect it's not covered in comps right either - Jens, what's the > > logic behind this? > > Right various languages should probably be added to comps: this will > certainly happen for Indian scripts at least which I'm currently > working on. If it's required by other packages, it should just be required by those packages instead of requiring an explicit selection. > On the other hand of course not every language needs to be comps either: > I don't think most Swedes say need to have m17n-db-swedish installed > for example. If it doesn't need to be in comps, then why does it need to be shipped? Jeremy From selinux at gmail.com Fri Feb 3 16:38:43 2006 From: selinux at gmail.com (Tom London) Date: Fri, 3 Feb 2006 08:38:43 -0800 Subject: rawhide report: 20060203 changes In-Reply-To: <4c4ba1530602030817t70b8a24fi92e172e4f45d4cd3@mail.gmail.com> References: <200602031549.k13FnTaM006152@porkchop.devel.redhat.com> <4c4ba1530602030817t70b8a24fi92e172e4f45d4cd3@mail.gmail.com> Message-ID: <4c4ba1530602030838l6aa35be3x7c0600188b9b8ddd@mail.gmail.com> Update seems to break touch: [tbl at localhost Devel]$ strace /bin/touch dbus.list execve("/bin/touch", ["/bin/touch", "dbus.list"], [/* 34 vars */]) = 0 brk(0) = 0x9930000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f21000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=54346, ...}) = 0 mmap2(NULL, 54346, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f13000 close(3) = 0 open("/lib/librt.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\0\260\34"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=37956, ...}) = 0 mmap2(NULL, 29260, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x63c000 mmap2(0x642000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5) = 0x642000 close(3) = 0 open("/lib/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\252X\1"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1493272, ...}) = 0 mmap2(NULL, 1213820, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x111000 mmap2(0x233000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x122) = 0x233000 mmap2(0x237000, 9596, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x237000 close(3) = 0 open("/lib/libpthread.so.0", 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\34I\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=100900, ...}) = 0 mmap2(NULL, 70076, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x5fe000 mmap2(0x60c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd) = 0x60c000 mmap2(0x60e000, 4540, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x60e000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f12000 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7f12aa0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 mprotect(0x60c000, 4096, PROT_READ) = 0 mprotect(0x233000, 12288, PROT_READ) = 0 mprotect(0x642000, 4096, PROT_READ) = 0 mprotect(0x2a5000, 4096, PROT_READ) = 0 munmap(0xb7f13000, 54346) = 0 set_tid_address(0xb7f12ae8) = 17511 rt_sigaction(SIGRTMIN, {0x602536, [], SA_SIGINFO}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0x602470, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=10240*1024, rlim_max=RLIM_INFINITY}) = 0 _sysctl({{CTL_KERN, KERN_VERSION}, 2, 0xbff20a80, 30, (nil), 0}) = 0 brk(0) = 0x9930000 brk(0x9951000) = 0x9951000 open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=54082992, ...}) = 0 mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7d12000 close(3) = 0 close(0) = 0 open("dbus.list", O_WRONLY|O_NONBLOCK|O_CREAT|O_NOCTTY|O_LARGEFILE, 0666) = 0 SYS_299(0, 0, 0, 0, 0x235ff4) = -1 EFAULT (Bad address) close(0) = 0 open("/usr/share/locale/locale.alias", O_RDONLY) = 0 fstat64(0, {st_mode=S_IFREG|0644, st_size=2528, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f20000 read(0, "# Locale name alias data base.\n#"..., 4096) = 2528 read(0, "", 4096) = 0 close(0) = 0 munmap(0xb7f20000, 4096) = 0 open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en_US.utf8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en_US/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en.UTF-8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en.utf8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory) write(2, "/bin/touch: ", 12/bin/touch: ) = 12 write(2, "setting times of `dbus.list\'", 28setting times of `dbus.list') = 28 open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) write(2, ": Bad address", 13: Bad address) = 13 write(2, "\n", 1 ) = 1 close(1) = 0 exit_group(1) = ? Process 17511 detached [tbl at localhost Devel]$ From davej at redhat.com Fri Feb 3 16:40:30 2006 From: davej at redhat.com (Dave Jones) Date: Fri, 3 Feb 2006 11:40:30 -0500 Subject: rawhide report: 20060203 changes In-Reply-To: <4c4ba1530602030838l6aa35be3x7c0600188b9b8ddd@mail.gmail.com> References: <200602031549.k13FnTaM006152@porkchop.devel.redhat.com> <4c4ba1530602030817t70b8a24fi92e172e4f45d4cd3@mail.gmail.com> <4c4ba1530602030838l6aa35be3x7c0600188b9b8ddd@mail.gmail.com> Message-ID: <20060203164030.GG24201@redhat.com> On Fri, Feb 03, 2006 at 08:38:43AM -0800, Tom London wrote: > Update seems to break touch: The kernel implemented a new syscall which glibc started using. Some apps were passing values it wasn't quite prepared for. Jakub fixed the problem, so hopefully the next glibc update should fix it. Dave From gazzerh at gmail.com Fri Feb 3 16:41:45 2006 From: gazzerh at gmail.com (Garry Harthill) Date: Fri, 3 Feb 2006 16:41:45 +0000 Subject: rawhide report: 20060203 changes In-Reply-To: <43E38052.8080408@redhat.com> References: <200602031549.k13FnTaM006152@porkchop.devel.redhat.com> <1fcc9e320602030759n139d4860x@mail.gmail.com> <43E38052.8080408@redhat.com> Message-ID: <1fcc9e320602030841t3742c47et@mail.gmail.com> > Ah, now that I've found your question (next time please abridge the text > you're replying to, or at the very least post at the top so we can find > it), you're looking for the wrong package on the wrong day. This was > fixed already yesterday, and by python-sqlite, not sqlite, which was > also pointed out several times on this list already. Sorry about the loooong reply I posted. Google is very nice at minimizing all that so sometimes I forget that other clients don't do this. Anyway, updated the RPM and all is working. Why the package name change? Cheers, Garry From notting at redhat.com Fri Feb 3 16:44:33 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 3 Feb 2006 11:44:33 -0500 Subject: rawhide report: 20060203 changes In-Reply-To: <1fcc9e320602030841t3742c47et@mail.gmail.com> References: <200602031549.k13FnTaM006152@porkchop.devel.redhat.com> <1fcc9e320602030759n139d4860x@mail.gmail.com> <43E38052.8080408@redhat.com> <1fcc9e320602030841t3742c47et@mail.gmail.com> Message-ID: <20060203164433.GB8387@devserv.devel.redhat.com> Garry Harthill (gazzerh at gmail.com) said: > Sorry about the loooong reply I posted. Google is very nice at > minimizing all that so sometimes I forget that other clients don't do > this. > > Anyway, updated the RPM and all is working. Why the package name change? Wasn't a name change - it was just that the sqlite update exposed a python-sqlite bug. Bill From steve at silug.org Fri Feb 3 16:45:35 2006 From: steve at silug.org (Steven Pritchard) Date: Fri, 3 Feb 2006 10:45:35 -0600 Subject: mock + ccache? (was Re: nothing from buildsys?) In-Reply-To: <43E32D5A.5050907@mharris.ca> References: <43E1E0BE.2080908@adslpipe.co.uk> <5256d0b0602020239s3aa68266p37346bfc4d493c12@mail.gmail.com> <43E1F427.3050701@reub.net> <43E32D5A.5050907@mharris.ca> Message-ID: <20060203164535.GA20256@osiris.silug.org> On Fri, Feb 03, 2006 at 05:15:54AM -0500, Mike A. Harris wrote: > If you've got a 1.5Ghz CPU or faster, and install "ccache" from Fedora > Extras, your machine will build pretty much any package faster than > our buildsystem. ;o) That reminds me... Has anyone ever tried to tie mock and ccache together somehow? It seems like that would speed up repeated build attempts noticably. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From gazzerh at gmail.com Fri Feb 3 16:47:52 2006 From: gazzerh at gmail.com (Garry Harthill) Date: Fri, 3 Feb 2006 16:47:52 +0000 Subject: rawhide report: 20060203 changes In-Reply-To: <20060203164433.GB8387@devserv.devel.redhat.com> References: <200602031549.k13FnTaM006152@porkchop.devel.redhat.com> <1fcc9e320602030759n139d4860x@mail.gmail.com> <43E38052.8080408@redhat.com> <1fcc9e320602030841t3742c47et@mail.gmail.com> <20060203164433.GB8387@devserv.devel.redhat.com> Message-ID: <1fcc9e320602030847v76d796b7l@mail.gmail.com> > Wasn't a name change - it was just that the sqlite update exposed > a python-sqlite bug. > > Bill Ok. Thanks From caillon at redhat.com Fri Feb 3 16:48:00 2006 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 03 Feb 2006 11:48:00 -0500 Subject: rawhide report: 20060203 changes In-Reply-To: <1fcc9e320602030841t3742c47et@mail.gmail.com> References: <200602031549.k13FnTaM006152@porkchop.devel.redhat.com> <1fcc9e320602030759n139d4860x@mail.gmail.com> <43E38052.8080408@redhat.com> <1fcc9e320602030841t3742c47et@mail.gmail.com> Message-ID: <43E38940.3030308@redhat.com> On 02/03/2006 11:41 AM, Garry Harthill wrote: > Anyway, updated the RPM and all is working. Why the package name change? It didn't. The sqlite update exposed a bug in the python bindings, which yum happens to use. From kloczek at zie.pg.gda.pl Fri Feb 3 16:50:48 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=) Date: Fri, 03 Feb 2006 17:50:48 +0100 Subject: propozition of specs cleanups In-Reply-To: <43E34B61.9000809@fedoraproject.org> References: <1138959257.25983.84.camel@kloczek01.pracownicy.zie> <43E3302C.2070602@mharris.ca> <1138965417.25983.133.camel@kloczek01.pracownicy.zie> <43E34156.9030402@fedoraproject.org> <1138968719.25983.142.camel@kloczek01.pracownicy.zie> <43E34B61.9000809@fedoraproject.org> Message-ID: <1138985448.25983.182.camel@kloczek01.pracownicy.zie> Dnia 03-02-2006, pi? o godzinie 17:54 +0530, Rahul Sundaram napisa?(a): [..] > >Good to know you focus on my expression (not on sense chages). > > > > > The expression is as atleast as important as the changes being proposed. > There is no point in being rude unnecessarily. It certainly cant > motivate the developers to get involved to do the changes. Sorry but my rude expression it is reaction on submiting many separated BR via bugzilla for *very* small changes in many packages. There is no leader in fedora development team or someone other hwo watch on all traffic in CVS or other persons who can commit some mainly stylistics changes ? If no .. look on current form od FC spec files. So many styles as many developers. This it makes much more harder for any developers .. this is like idendenting .c files. Few years ago I itroduce using common specs style in PLD. This was done by very simple awk script (if anyone don't know why it have so common form). Transform specs files to some common form allow catch many bugs in specs. For example many FC specs do not have "rm -rf $RPM_BUILD_ROOT" on top %install breaks --short-circuit %install only build. Next: many specs files produces main package and devel. For prevent some hazard dependencies best will be add in devel "Requires: %{name} = %{version}-%{release}" or even "Requires: %{name} = %{epoch}:{version}-%{release}" if package have Epoch. If you want more I have *very long* list of this kind things. but IMO best will be introduce all this one by one for aprove and inform in best possible way all developers about some common rules on maintainig specs. Do you see now most of this kind changes can be performed by single perl/sed regexp ? if yes .. ask: why the hell for change N single line cleanups in N spec files must be involved N developers ? this single change and require single developer who can commit this with aprove all other developers. IMO best way for introduce this kind changes will be make propozition of this kind changes (one by one or in small groups) for discuss -> after pass few days for discuss and without protests -> performe single commit by someon who have permission for this kind stylistics/cosmetics changes for making this like "shoot and forget" without absorbe each developer for making each single line/small adjustment. Ones more: I'm not talking about bugs or critical bugs. I'm talking about prepare some kind of "common spec coding style". If introducing this kind chanes will be possible only via bugzilla for each package this will create unnormal amout of traffic in bugzill wich can stop many people for many days or weeks. Do you see this now ? > >If you want my time for spending on bugzilla -> please pay me for this > >(sorry) or show me how can I introduce in time frame comparable to time > >spend on thinking on sed line > > > > > It probably can be done within the buildsystem to enforce such things. > Meanwhile if you dont want to voluntarily spend the time involved in > reporting this changes to the individual developers through bugzilla > feel free to drop it but several people have done similar things before. Hanging this in build system is bad point. This will be like indenting .c files on compile stage. kloczek From naheemzaffar at gmail.com Fri Feb 3 16:52:52 2006 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Fri, 3 Feb 2006 16:52:52 +0000 Subject: Rawhide performance? In-Reply-To: <43E1A622.2070704@fedoraproject.org> References: <1138835047.3324.91.camel@mentorng.gurulabs.com> <3adc77210602011537l5d8d9683u15ad71eda6a08f0a@mail.gmail.com> <43E1A622.2070704@fedoraproject.org> Message-ID: <3adc77210602030852q216eafa9v1dd9d938db6efeb0@mail.gmail.com> >On 2/2/06, Rahul Sundaram >>wrote:Naheem Zaffar wrote: >> Adding a further question, should I file a bug against the combined >> rad-hat menu? it waits til it is first clicked on to check for >> updates. The Gnome default menu (three buttons applications, and the >> other two) seems to work straight away. >Which updates? Updates to the .desktop files.(I may be talking from the rear though... that is a guess...) > The combined menu seems to have got faster since yesterday I think... > > but it still takes a noticeable amount of time, as (I assume) it is > > looking for the desktop files after being clicked on for the first time. > > How many seconds of difference is there between the RH menu and the > stock GNOME menu? My system: Pentium 3 667mhz. 768 MB of 133 SDRAM. Latest Rawhide (3 February... test carried out after full update at 3pm UK time...) Testing: try one menu type, reboot, try other. Wait til everything is loaded before trying. timing method: 1 elephant, 2 elephant, 3 elephant. (Sorry... that loses this 'test' alot of credibility...) 1. Combined menu: Approx 7 seconds on a cold boot. 2. Default gnome-menu: immediate. 0 seconds on cold boot. 3. after logging out and logging back in without a reboot, the combined menu still takes around 1.5 seconds. These times feel faster than it was taking a few days before my first post. (I mentioned I felt a speed up a few days prior to that email...). And the system is frozen while the combined menu does its thing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kengert at redhat.com Fri Feb 3 17:03:42 2006 From: kengert at redhat.com (Kai Engert) Date: Fri, 03 Feb 2006 18:03:42 +0100 Subject: Replace mozilla with SeaMonkey? In-Reply-To: <20060203044733.AD2A173160@hormel.redhat.com> References: <20060203044733.AD2A173160@hormel.redhat.com> Message-ID: <43E38CEE.3080506@redhat.com> Jim Cornette wrote: > Would they use the same profile as Netscape 7 does? The query is mainly > due to email accounts, bookmarks are rather large. I don't think needing > to import all this information into another profile would be desirable. > The different directories for Thunderbird and for mozilla are one > feature that I do not care for. > Seamonkey uses the same profile in the same directory as the former Mozilla 1.7.x suite. Kai -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3248 bytes Desc: S/MIME Cryptographic Signature URL: From jspaleta at gmail.com Fri Feb 3 17:13:33 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 3 Feb 2006 12:13:33 -0500 Subject: propozition of specs cleanups In-Reply-To: <1138985448.25983.182.camel@kloczek01.pracownicy.zie> References: <1138959257.25983.84.camel@kloczek01.pracownicy.zie> <43E3302C.2070602@mharris.ca> <1138965417.25983.133.camel@kloczek01.pracownicy.zie> <43E34156.9030402@fedoraproject.org> <1138968719.25983.142.camel@kloczek01.pracownicy.zie> <43E34B61.9000809@fedoraproject.org> <1138985448.25983.182.camel@kloczek01.pracownicy.zie> Message-ID: <604aa7910602030913n92ab367q6ef3ec0671a54634@mail.gmail.com> On 2/3/06, Tomasz K?oczko wrote: > IMO best way for introduce this kind changes will be make propozition of > this kind changes (one by one or in small groups) for discuss -> after > pass few days for discuss and without protests -> performe single commit > by someon who have permission for this kind stylistics/cosmetics changes > for making this like "shoot and forget" without absorbe each developer > for making each single line/small adjustment. I think making these small changes... even if you script them.. is absolutely pointless until you there is a concensous from the Core developers to use agreed on spec templates and style rules. Trying to apply what you think are appropriate stylistic rules for specfiles without the developers who are maintaining the packages agreeing to consistently use that style in the future just makes work for everyone. You are fixing the wrong problem and you are fixing it the wrong way. If your goal is to have all the Core spec files be produced in a consistent manner then you will need to convince the Core developers to use a consistent style (and you can't do that by calling them stupid or inexperienced). Going back and "fixing" the specfiles without the maintainers agreeing with the style changes you want to enforce is a short-circuit hack which avoids the underlying problem of concensous. -jef"You catch more flies with honey, and you catch more developers with pizza"spaleta From kloczek at zie.pg.gda.pl Fri Feb 3 17:37:43 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=) Date: Fri, 03 Feb 2006 18:37:43 +0100 Subject: propozition of specs cleanups In-Reply-To: <604aa7910602030913n92ab367q6ef3ec0671a54634@mail.gmail.com> References: <1138959257.25983.84.camel@kloczek01.pracownicy.zie> <43E3302C.2070602@mharris.ca> <1138965417.25983.133.camel@kloczek01.pracownicy.zie> <43E34156.9030402@fedoraproject.org> <1138968719.25983.142.camel@kloczek01.pracownicy.zie> <43E34B61.9000809@fedoraproject.org> <1138985448.25983.182.camel@kloczek01.pracownicy.zie> <604aa7910602030913n92ab367q6ef3ec0671a54634@mail.gmail.com> Message-ID: <1138988263.25664.2.camel@kloczek01.pracownicy.zie> Dnia 03-02-2006, pi? o godzinie 12:13 -0500, Jeff Spaleta napisa?(a): > On 2/3/06, Tomasz K?oczko wrote: > > IMO best way for introduce this kind changes will be make propozition of > > this kind changes (one by one or in small groups) for discuss -> after > > pass few days for discuss and without protests -> performe single commit > > by someon who have permission for this kind stylistics/cosmetics changes > > for making this like "shoot and forget" without absorbe each developer > > for making each single line/small adjustment. > > I think making these small changes... even if you script them.. is > absolutely pointless until you there is a concensous from the Core > developers to use agreed on spec templates and style rules. Read again my previouse email. This is what I was write :) > Trying to apply what you think are appropriate stylistic rules for specfiles > without the developers who are maintaining the packages agreeing to > consistently use that style in the future just makes work for > everyone. Tring to keep population spec files without common coding style will make harder and harder maintaining this even for developers with CVS r/w access (think about people like me who want look on this only ocasionaly). > You are fixing the wrong problem and you are fixing it the wrong way. > > If your goal is to have all the Core spec files be produced in a > consistent manner then you will need to convince the Core developers > to use a consistent style (and you can't do that by calling them > stupid or inexperienced). Sorry (for my rude eagain) .. but I'm not talking with Core developers ? 8-o Who is the boss/leader of the team ? If I'm talk with FC developers .. is it above mean to submiting bugzilla BR I must add time for talk one by one with each developer ? If yes .. before it was stupid but now it make all this plain nonsens :> I do not have CVS rw access and do not want to have this. I want talk with persons responsible on specs coding style. kloczek From jkeating at redhat.com Fri Feb 3 18:02:44 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 03 Feb 2006 10:02:44 -0800 Subject: nothing from buildsys? In-Reply-To: <43E32AAE.2030703@mharris.ca> References: <43E1E0BE.2080908@adslpipe.co.uk> <5256d0b0602020239s3aa68266p37346bfc4d493c12@mail.gmail.com> <43E32AAE.2030703@mharris.ca> Message-ID: <1138989764.2863.28.camel@yoda.loki.me> On Fri, 2006-02-03 at 05:04 -0500, Mike A. Harris wrote: > > So.... What is this unified across all platforms srpm repo you speak > of, and how does it differ from what we've been doing internally for > about 4 years? ;o) That was my blog. What we have now once the packages are all built and we want to make an installable tree set, we build one binary package set and one source package set for each arch. As you say, the srpms are common across all the platforms, but there are some packages that only get included on one arch or another. This causes the srpm isos to not be exactly the same and unlinkable. To save space / time I am modifying our tree building software to create ONE master srpm package / cd set from all the srpms uses across all the arches we ship (in fedora thats i386, x86_64, and ppc). So instead of each arch havning a SRPMS/ dir and a SRPM CD set, there will be one top level sources/ dir that has a global SRPMS/ dir and an iso dir with isos made from the unified SRPMS. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-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 Feb 3 18:06:37 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 3 Feb 2006 19:06:37 +0100 Subject: nothing from buildsys? In-Reply-To: <1138989764.2863.28.camel@yoda.loki.me> References: <43E1E0BE.2080908@adslpipe.co.uk> <5256d0b0602020239s3aa68266p37346bfc4d493c12@mail.gmail.com> <43E32AAE.2030703@mharris.ca> <1138989764.2863.28.camel@yoda.loki.me> Message-ID: <20060203190637.41c14cd7@python2> Jesse Keating wrote : > On Fri, 2006-02-03 at 05:04 -0500, Mike A. Harris wrote: > > > > So.... What is this unified across all platforms srpm repo you speak > > of, and how does it differ from what we've been doing internally for > > about 4 years? ;o) > > That was my blog. What we have now once the packages are all built and > we want to make an installable tree set, we build one binary package set > and one source package set for each arch. As you say, the srpms are > common across all the platforms, but there are some packages that only > get included on one arch or another. This causes the srpm isos to not > be exactly the same and unlinkable. To save space / time I am modifying > our tree building software to create ONE master srpm package / cd set > from all the srpms uses across all the arches we ship (in fedora thats > i386, x86_64, and ppc). So instead of each arch havning a SRPMS/ dir > and a SRPM CD set, there will be one top level sources/ dir that has a > global SRPMS/ dir and an iso dir with isos made from the unified SRPMS. This is great news, and will make the mirror admins happy, especially since last I checked there were only two or three packages differing between the i386 and x86_64 source CDs... and I doubt there are more than another handful for ppc :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1656_FC4 Load : 0.58 0.52 0.73 From ndbecker2 at gmail.com Fri Feb 3 18:10:26 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 03 Feb 2006 13:10:26 -0500 Subject: koffice + bakoma fonts Message-ID: I noticed that the kformula manual recommends installing bakoma fonts, but I don't see them available from yum. Would be nice to have an rpm package. I'm assuming that all we need is the TTFs? From jspaleta at gmail.com Fri Feb 3 18:12:33 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 3 Feb 2006 13:12:33 -0500 Subject: propozition of specs cleanups In-Reply-To: <1138988263.25664.2.camel@kloczek01.pracownicy.zie> References: <1138959257.25983.84.camel@kloczek01.pracownicy.zie> <43E3302C.2070602@mharris.ca> <1138965417.25983.133.camel@kloczek01.pracownicy.zie> <43E34156.9030402@fedoraproject.org> <1138968719.25983.142.camel@kloczek01.pracownicy.zie> <43E34B61.9000809@fedoraproject.org> <1138985448.25983.182.camel@kloczek01.pracownicy.zie> <604aa7910602030913n92ab367q6ef3ec0671a54634@mail.gmail.com> <1138988263.25664.2.camel@kloczek01.pracownicy.zie> Message-ID: <604aa7910602031012q180b2919o3ac9f4bc0d96007@mail.gmail.com> On 2/3/06, Tomasz K?oczko wrote: > Read again my previouse email. This is what I was write :) I don't see aything in what you wrote that provides a mechanism to encourage Core developers to consistently use a defined style. I see no description of a re-education program nor do I see you suggesting that new packages to Core must go through a pre-submission review process. Things are not going to get better in terms of style in Core specs unless indvidual maintainers are willing to change their habits. I think you brushed aside Mike's explanation of how he writes specfiles over several revisions a bit too quickly. Nor did you even attempt to describe a different mechanism for Mike to use to replace his specfile coding method. Style is a habit. You don't fix inconsistent styles by going back and editting what people wrote. You fix it by finding ways to get the developers to change their habits. I don't see you making any attempt here to address the underlying bad habits. > Sorry (for my rude eagain) .. but I'm not talking with Core developers ? I'm pretty sure there is no requirement that Core developers actively read all threads in this list. There may be very few maintainers watching this thread at this point. At best you are talking to a few developers and a lot of people(like me) who just like to talk. > I do not have CVS rw access and do not want to have this. I want talk > with persons responsible on specs coding style. Is there someone responsble for spec style in Core? I highly doubt that there is a person tapped with that sort of janitorial duty. You also seem to have an unwritten assumption that Core maintainers are willing to conform to a single coding style. -jef"being a good idea salesman doesn't involve bullying people into accepting your ideas to solve your problems... it involves showing them how your ideas solve their problems. I haven't seen you attempt address Mike's problem"spaleta From ivazquez at ivazquez.net Fri Feb 3 18:44:36 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 03 Feb 2006 13:44:36 -0500 Subject: mock + ccache? (was Re: nothing from buildsys?) In-Reply-To: <20060203164535.GA20256@osiris.silug.org> References: <43E1E0BE.2080908@adslpipe.co.uk> <5256d0b0602020239s3aa68266p37346bfc4d493c12@mail.gmail.com> <43E1F427.3050701@reub.net> <43E32D5A.5050907@mharris.ca> <20060203164535.GA20256@osiris.silug.org> Message-ID: <1138992276.5160.2.camel@ignacio.lan> On Fri, 2006-02-03 at 10:45 -0600, Steven Pritchard wrote: > That reminds me... Has anyone ever tried to tie mock and ccache > together somehow? It seems like that would speed up repeated build > attempts noticably. It is potentially possible, but the problem is that ccache has in the past caused build issues from time to time for various people outside of mock. I dare not think what chaos it could wreak in a semi-automated buildsystem. distcc *might* be a better choice, once it's ready. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Fri Feb 3 19:22:04 2006 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 03 Feb 2006 14:22:04 -0500 Subject: mock + ccache? (was Re: nothing from buildsys?) In-Reply-To: <1138992276.5160.2.camel@ignacio.lan> References: <43E1E0BE.2080908@adslpipe.co.uk> <5256d0b0602020239s3aa68266p37346bfc4d493c12@mail.gmail.com> <43E1F427.3050701@reub.net> <43E32D5A.5050907@mharris.ca> <20060203164535.GA20256@osiris.silug.org> <1138992276.5160.2.camel@ignacio.lan> Message-ID: <1138994525.2652.17.camel@bree.local.net> On Fri, 2006-02-03 at 13:44 -0500, Ignacio Vazquez-Abrams wrote: > On Fri, 2006-02-03 at 10:45 -0600, Steven Pritchard wrote: > > That reminds me... Has anyone ever tried to tie mock and ccache > > together somehow? It seems like that would speed up repeated build > > attempts noticably. > > It is potentially possible, but the problem is that ccache has in the > past caused build issues from time to time for various people outside of > mock. I dare not think what chaos it could wreak in a semi-automated > buildsystem. distcc *might* be a better choice, once it's ready. If you think make -j causes problems for people... :-) I think that ccache is potentially helpful for people when they're testing locally and trying to get stuff working, but I definitely wouldn't want it enabled for production builds Jeremy From michael at knox.net.nz Fri Feb 3 19:35:29 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sat, 04 Feb 2006 08:35:29 +1300 Subject: e1000 in rawhide kernel In-Reply-To: <5256d0b0602030116l2f1415daofaa13ab36f7d22f3@mail.gmail.com> References: <1138925360.3728.5.camel@nemausa.et.endace.com> <1138957442.21385.2.camel@localhost.localdomain> <5256d0b0602030116l2f1415daofaa13ab36f7d22f3@mail.gmail.com> Message-ID: <1138995330.21901.4.camel@pingu.homenetwork.lan> On Fri, 2006-02-03 at 09:16 +0000, Peter Robinson wrote: > On 2/3/06, Nigel Metheringham wrote: > > On Fri, 2006-02-03 at 13:08 +1300, Michael J Knox wrote: > > > I have a 82573E onboard NIC that refuses to obtain a DHCP IP. If its > > > statically asigned, I am ok. > > > > Try getting the port you are connected to set to (say) 100 MB FD with no > > autonegotiation, and see if that works better. Some network > > switches/NIC combos seem to take for ever to negotiate the link. Quite > > whose fault this is I don't know, although one network equipment > > manufacturer seems to be always involved. > > The higher end ones take ages to negotiate because they try and neg > Spanning Tree Protocol first so the port goes through a blocking, > discovery and then is finally into the forwarding stage. This normally > doesn't cause a problem with newer NICs but it use to be very painful > on older NICs with Netware as the netware drivers would time out. > > Not sure if this would be an issue but one other thing to look at is > to make sure your not running and extremely tight custom firewall that > blocks the dhcp response packets. Also does it work if you temporarily > set a static IP. > > Pete Is 12 hours long enough? I reboot into the XP partition and the link is up straight away with an IP address. Likewise with the debian etch install on a different box using the same motherboard. Michael From rdieter at math.unl.edu Fri Feb 3 19:39:08 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 03 Feb 2006 13:39:08 -0600 Subject: koffice + bakoma fonts In-Reply-To: References: Message-ID: <43E3B15C.2020003@math.unl.edu> Neal Becker wrote: > I noticed that the kformula manual recommends installing bakoma fonts, but I > don't see them available from yum. Would be nice to have an rpm package. mathml-fonts in Extras includes those bits. -- Rex From rdieter at math.unl.edu Fri Feb 3 19:40:31 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 03 Feb 2006 13:40:31 -0600 Subject: koffice + bakoma fonts In-Reply-To: <43E3B15C.2020003@math.unl.edu> References: <43E3B15C.2020003@math.unl.edu> Message-ID: <43E3B1AF.7050000@math.unl.edu> Rex Dieter wrote: > Neal Becker wrote: >> I noticed that the kformula manual recommends installing bakoma fonts, >> but I >> don't see them available from yum. Would be nice to have an rpm package. > mathml-fonts in Extras includes those bits. And, which is why koffice-kformula (also in Extras) includes: Requires: mathml-fonts (-: -- Rex From steve at silug.org Fri Feb 3 20:05:12 2006 From: steve at silug.org (Steven Pritchard) Date: Fri, 3 Feb 2006 14:05:12 -0600 Subject: mock + ccache? (was Re: nothing from buildsys?) In-Reply-To: <1138994525.2652.17.camel@bree.local.net> References: <43E1E0BE.2080908@adslpipe.co.uk> <5256d0b0602020239s3aa68266p37346bfc4d493c12@mail.gmail.com> <43E1F427.3050701@reub.net> <43E32D5A.5050907@mharris.ca> <20060203164535.GA20256@osiris.silug.org> <1138992276.5160.2.camel@ignacio.lan> <1138994525.2652.17.camel@bree.local.net> Message-ID: <20060203200512.GA24199@osiris.silug.org> On Fri, Feb 03, 2006 at 02:22:04PM -0500, Jeremy Katz wrote: > I think that ccache is potentially helpful for people when they're > testing locally and trying to get stuff working, but I definitely > wouldn't want it enabled for production builds Oh, no, definitely not. I was thinking for local testing, such as for the last half-dozen times I've fired off a mock build of cone on rawhide. :-) Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From mitr at volny.cz Fri Feb 3 20:51:40 2006 From: mitr at volny.cz (Miloslav Trmac) Date: Fri, 03 Feb 2006 21:51:40 +0100 Subject: propozition of specs cleanups In-Reply-To: <1138988263.25664.2.camel@kloczek01.pracownicy.zie> References: <1138959257.25983.84.camel@kloczek01.pracownicy.zie> <43E3302C.2070602@mharris.ca> <1138965417.25983.133.camel@kloczek01.pracownicy.zie> <43E34156.9030402@fedoraproject.org> <1138968719.25983.142.camel@kloczek01.pracownicy.zie> <43E34B61.9000809@fedoraproject.org> <1138985448.25983.182.camel@kloczek01.pracownicy.zie> <604aa7910602030913n92ab367q6ef3ec0671a54634@mail.gmail.com> <1138988263.25664.2.camel@kloczek01.pracownicy.zie> Message-ID: <43E3C25C.3050808@volny.cz> Hi, Tomasz K?oczko wrote: > Dnia 03-02-2006, pi? o godzinie 12:13 -0500, Jeff Spaleta napisa?(a): >>Trying to apply what you think are appropriate stylistic rules for specfiles >>without the developers who are maintaining the packages agreeing to >>consistently use that style in the future just makes work for >>everyone. > > Tring to keep population spec files without common coding style will > make harder and harder maintaining this even for developers with CVS r/w > access (think about people like me who want look on this only > ocasionaly). I don't think we want people who are confused by empty %doc to maintain RPM packages ;) Real packaging bugs are hopefully rare and can be dealt with one at a time via bugzilla. "Potential packaging bugs" like using ../man/foo* instead of ../man/foo.gz, which are not a problem with redhat-rpm-config, and purely stylistic issues are IMHO not worth worrying about at all. There are 6316 open bugs against Fedora right now and the discussion (and likely disagreement) about stylistic issues with no functional impact does not noticeably help fixing the real bugs nor developing new features. Mirek From katzj at redhat.com Fri Feb 3 22:39:47 2006 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 03 Feb 2006 17:39:47 -0500 Subject: Fedora Core 5 Test 3 Slip Message-ID: <1139006387.2652.29.camel@bree.local.net> Although I hate to do it, it looks like we're going to have to slip Fedora Core 5 test3 by a week. There is an ABI change in the gcc/glibc stack that requires a rebuild of the entire distribution. Given that, there is no way that we'll be able to make a freeze date of Monday. So, test3 will now freeze on Monday, 13 February with a release date of Monday, 20 February. We'll adjust the final schedule sometime next week based on the progress of the rebuilding efforts. Thanks, Jeremy From ndbecker2 at gmail.com Sat Feb 4 00:12:16 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 03 Feb 2006 19:12:16 -0500 Subject: anaconda request - retry on network download failure References: <1138917494.3451.17.camel@bree.local.net> Message-ID: Jeremy Katz wrote: > On Thu, 2006-02-02 at 13:37 -0500, Neal Becker wrote: >> When using network installation, it SURE would be nice if anaconda gave a >> choice to retry a failed package download! > > It should already be possible... if not, that's a bug (although before > even asking, it should be trying a few times > I just did an install from FC5T2 boot disk, and 2 times it errored out, crashing anaconda. I had tried to use ftp to redhat. The 3rd time I used duke ftp, and install completed. So, I'm afraid there's a bug. From katzj at redhat.com Sat Feb 4 00:17:43 2006 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 03 Feb 2006 19:17:43 -0500 Subject: anaconda request - retry on network download failure In-Reply-To: References: <1138917494.3451.17.camel@bree.local.net> Message-ID: <1139012263.2652.41.camel@bree.local.net> On Fri, 2006-02-03 at 19:12 -0500, Neal Becker wrote: > Jeremy Katz wrote: > > On Thu, 2006-02-02 at 13:37 -0500, Neal Becker wrote: > >> When using network installation, it SURE would be nice if anaconda gave a > >> choice to retry a failed package download! > > > > It should already be possible... if not, that's a bug (although before > > even asking, it should be trying a few times > > > > I just did an install from FC5T2 boot disk, and 2 times it errored out, > crashing anaconda. I had tried to use ftp to redhat. The 3rd time I used > duke ftp, and install completed. So, I'm afraid there's a bug. Can you file it so that it's somewhere that we can track it instead of having it just floating around via email where we'll forget about it? :) Jeremy From icon at fedoraproject.org Sat Feb 4 00:25:37 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Fri, 03 Feb 2006 19:25:37 -0500 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <1139006387.2652.29.camel@bree.local.net> References: <1139006387.2652.29.camel@bree.local.net> Message-ID: <43E3F481.9080800@fedoraproject.org> ? 03/02/06 05:39 PM, Jeremy Katz a ?crit: > Although I hate to do it, it looks like we're going to have to slip > Fedora Core 5 test3 by a week. There is an ABI change in the gcc/glibc > stack that requires a rebuild of the entire distribution. Given that, > there is no way that we'll be able to make a freeze date of Monday. So, > test3 will now freeze on Monday, 13 February with a release date of > Monday, 20 February. > > We'll adjust the final schedule sometime next week based on the progress > of the rebuilding efforts. Hey, Jeremy: How will this affect the readiness of Extras for FC5? About 4 weeks ago we were asked to rebuild our packages if we hadn't done that in a while -- in order to be ready for FC5. Will this have to be re-done? (Not complaining, just asking. :)) Regards, -- Konstantin Ryabitsev McGill University WSG Montr?al, Qu?bec From igorm5 at vip.hr Sat Feb 4 00:38:36 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Sat, 04 Feb 2006 01:38:36 +0100 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <1139006387.2652.29.camel@bree.local.net> References: <1139006387.2652.29.camel@bree.local.net> Message-ID: <43E3F78C.8030602@vip.hr> Jeremy Katz wrote: > Although I hate to do it, it looks like we're going to have to slip > Fedora Core 5 test3 by a week. There is an ABI change in the gcc/glibc > stack that requires a rebuild of the entire distribution. Given that, > there is no way that we'll be able to make a freeze date of Monday. So, > test3 will now freeze on Monday, 13 February with a release date of > Monday, 20 February. > We'll adjust the final schedule sometime next week based on the progress > of the rebuilding efforts. Well, I suppose that FC5 final is going to be released somewhere about my birthday (26th of March)... it's going to be a very nice birthday gift thoe ;) -- Igor Jagec From jkeating at redhat.com Sat Feb 4 00:48:27 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 03 Feb 2006 16:48:27 -0800 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <43E3F481.9080800@fedoraproject.org> References: <1139006387.2652.29.camel@bree.local.net> <43E3F481.9080800@fedoraproject.org> Message-ID: <1139014107.2863.63.camel@yoda.loki.me> On Fri, 2006-02-03 at 19:25 -0500, Konstantin Ryabitsev wrote: > Hey, Jeremy: > > How will this affect the readiness of Extras for FC5? About 4 weeks > ago we were asked to rebuild our packages if we hadn't done that in > a while -- in order to be ready for FC5. Will this have to be re-done? > > (Not complaining, just asking. :)) Yes, once we've rebuilt FC5, FE5 should be rebuilt as well. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-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 redhat.com Sat Feb 4 00:50:00 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 03 Feb 2006 16:50:00 -0800 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <43E3F78C.8030602@vip.hr> References: <1139006387.2652.29.camel@bree.local.net> <43E3F78C.8030602@vip.hr> Message-ID: <1139014200.2863.65.camel@yoda.loki.me> On Sat, 2006-02-04 at 01:38 +0100, Igor Jagec wrote: > Well, I suppose that FC5 final is going to be released somewhere about > my birthday (26th of March)... it's going to be a very nice birthday > gift thoe ;) My birthday being the 13th of march means that I'll be working very hard during that time to make sure FC5 is a great release for YOUR birthday (; -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From che666 at gmail.com Sat Feb 4 00:55:35 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Sat, 4 Feb 2006 01:55:35 +0100 Subject: mock + ccache? (was Re: nothing from buildsys?) In-Reply-To: <20060203200512.GA24199@osiris.silug.org> References: <43E1E0BE.2080908@adslpipe.co.uk> <5256d0b0602020239s3aa68266p37346bfc4d493c12@mail.gmail.com> <43E1F427.3050701@reub.net> <43E32D5A.5050907@mharris.ca> <20060203164535.GA20256@osiris.silug.org> <1138992276.5160.2.camel@ignacio.lan> <1138994525.2652.17.camel@bree.local.net> <20060203200512.GA24199@osiris.silug.org> Message-ID: 2006/2/3, Steven Pritchard : > On Fri, Feb 03, 2006 at 02:22:04PM -0500, Jeremy Katz wrote: > > I think that ccache is potentially helpful for people when they're > > testing locally and trying to get stuff working, but I definitely > > wouldn't want it enabled for production builds > > Oh, no, definitely not. I was thinking for local testing, such as for > the last half-dozen times I've fired off a mock build of cone on > rawhide. :-) > > Steve > -- > Steven Pritchard - K&S Pritchard Enterprises, Inc. > Email: steve at kspei.com http://www.kspei.com/ > Phone: (618)398-3000 Mobile: (618)567-7320 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > you can combine distcc and ccache. i got rather good long time experience with ccache in a non automated environment. if there are problems we should fix em i guess. and the best way to find problems is to use it extensively. regards, rudolf kastl From lamont at gurulabs.com Fri Feb 3 20:02:34 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Fri, 3 Feb 2006 13:02:34 -0700 Subject: e1000 in rawhide kernel In-Reply-To: <5256d0b0602030116l2f1415daofaa13ab36f7d22f3@mail.gmail.com> References: <1138925360.3728.5.camel@nemausa.et.endace.com> <1138957442.21385.2.camel@localhost.localdomain> <5256d0b0602030116l2f1415daofaa13ab36f7d22f3@mail.gmail.com> Message-ID: <200602031302.39171.lamont@gurulabs.com> On Friday 03 February 2006 02:16am, Peter Robinson wrote: > On 2/3/06, Nigel Metheringham wrote: > Not sure if this would be an issue but one other thing to look at is > to make sure your not running and extremely tight custom firewall that > blocks the dhcp response packets. Also does it work if you temporarily > set a static IP. Not possible. Try running this filewall config: ---- iptables -F iptables -t nat -F iptables -t mangle -F # For completeness, we would run three: # iptables -X # ..commands here, but it isn't necessary, this time iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT DROP iptables -t nat -P PREROUTING ACCEPT iptables -t nat -P OUTPUT ACCEPT iptables -t nat -P POSTROUTING ACCEPT iptables -t mangle -P PREROUTING ACCEPT iptables -t mangle -P INPUT ACCEPT iptables -t mangle -P FORWARD ACCEPT iptables -t mangle -P OUTPUT ACCEPT iptables -t mangle -P POSTROUTING ACCEPT # For completeness, we should: # iptables -A INPUT -i lo -j ACCEPT # iptables -A OUTPUT -o lo -j ACCEPT # ..here, but we won't in this example. ---- With this config in place, you would be allowing no traffic of any kind on any interface. If you're feeling pedantic, change the "ACCEPT"s to "DROP" but it won't change anything. I use ACCEPT because the filter table is where we make filtering decisions, not nat or mangle. On the machine with this firewall config, try to "ifup" your DHCP interface(s). Notice how it works? Netfilter will never block DHCP client-side (I've never tested this filewall config on the DHCP server; my first inclination is to expect that you could still get DHCP, but maybe not). Remember, there are *no* rules in this config allowing traffic of *any* kind. And yet, DHCP still works. This is an intentional feature in Netfilter. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lamont at gurulabs.com Fri Feb 3 19:14:22 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Fri, 3 Feb 2006 12:14:22 -0700 Subject: mock + ccache? (was Re: nothing from buildsys?) In-Reply-To: <1138992276.5160.2.camel@ignacio.lan> References: <43E1E0BE.2080908@adslpipe.co.uk> <20060203164535.GA20256@osiris.silug.org> <1138992276.5160.2.camel@ignacio.lan> Message-ID: <200602031214.26645.lamont@gurulabs.com> On Friday 03 February 2006 11:44am, Ignacio Vazquez-Abrams wrote: > On Fri, 2006-02-03 at 10:45 -0600, Steven Pritchard wrote: > > That reminds me... Has anyone ever tried to tie mock and ccache > > together somehow? It seems like that would speed up repeated build > > attempts noticably. > > It is potentially possible, but the problem is that ccache has in the > past caused build issues from time to time for various people outside of > mock. I dare not think what chaos it could wreak in a semi-automated > buildsystem. distcc *might* be a better choice, once it's ready. Instead of distcc, how about considering icecream? -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From avi at argo.co.il Sat Feb 4 01:10:26 2006 From: avi at argo.co.il (Avi Kivity) Date: Sat, 04 Feb 2006 03:10:26 +0200 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <1139006387.2652.29.camel@bree.local.net> References: <1139006387.2652.29.camel@bree.local.net> Message-ID: <43E3FF02.1060803@argo.co.il> Jeremy Katz wrote: >Although I hate to do it, it looks like we're going to have to slip >Fedora Core 5 test3 by a week. There is an ABI change in the gcc/glibc >stack that requires a rebuild of the entire distribution. Given that, > > Can you elaborate on this ABI change? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. From jakub at redhat.com Sat Feb 4 01:28:09 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 3 Feb 2006 20:28:09 -0500 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <43E3FF02.1060803@argo.co.il> References: <1139006387.2652.29.camel@bree.local.net> <43E3FF02.1060803@argo.co.il> Message-ID: <20060204012809.GP24295@devserv.devel.redhat.com> On Sat, Feb 04, 2006 at 03:10:26AM +0200, Avi Kivity wrote: > >Although I hate to do it, it looks like we're going to have to slip > >Fedora Core 5 test3 by a week. There is an ABI change in the gcc/glibc > >stack that requires a rebuild of the entire distribution. Given that, > > > > > Can you elaborate on this ABI change? We are changing long double type on ppc{32,64}, s390{,x}, sparc (32-bit), and alpha. Previously long double has been the same type as double on these architectures, now it will be either IEEE 754 quad format long double (112 (+1 implicit) bits mantissa, 15 bits exponent, 1 bit sign; on s390{,x}, sparc and alpha) or IBM extended format (pair of double values with some special rules). glibc has been changed so that it is backwards compatible with programs and shared libraries that use 64-bit long double, but also supports the 128-bit one, even when compiling packages you can choose the long double format (-mlong-double-64 resp. -mlong-double-128, which will be the new default). libstdc++.so.6 is also made backwards compatible with 64-bit long double, but supporting 128-bit long double as well (and similarly libgcc_s.so.1). In addition to this, there are other reasons why a complete rebuild of the entire distribution is desirable: 1) there used to be a bug on i?86 which caused incorrect .eh_frame section being generated (terminated before end of section), which makes e.g. valgrind complain loudly and also means .eh_frame_hdr can't be used to speed up exception handling. This bug has been fixed a long time ago, but many packages haven't been rebuilt since then. 2) on ia64 debug info wasn't properly describing function prologues 3) many binaries on ia64 were having text relocations, which is bad from security POV 4) on i?86 and x86_64, -mtune=generic option has been added, which means tuning for a pool of most commonly used CPUs. According to SPEC results the code is no worse than -mtune={nocona,pentium4} used before on Intel CPUs and is significantly better on AMD CPUs. Jakub From mailinglists at erwinrol.com Sat Feb 4 01:52:18 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sat, 04 Feb 2006 02:52:18 +0100 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <1139006387.2652.29.camel@bree.local.net> References: <1139006387.2652.29.camel@bree.local.net> Message-ID: <1139017938.7984.52.camel@xpc.home.erwinrol.com> On Fri, 2006-02-03 at 17:39 -0500, Jeremy Katz wrote: > There is an ABI change in the gcc/glibc > stack that requires a rebuild of the entire distribution. Since i was one (maybe even the only one ;-) that was complaining that rawhide broke last time, I ask this now; Does this ABI change cause random packages to break when doing "yum update" in the next few days ? With other words would it be smart to just wait until the complete rebuild is done before doing yum update again ? - Erwin From roland at redhat.com Sat Feb 4 01:59:59 2006 From: roland at redhat.com (Roland McGrath) Date: Fri, 3 Feb 2006 17:59:59 -0800 (PST) Subject: Fedora Core 5 Test 3 Slip In-Reply-To: Erwin Rol's message of Saturday, 4 February 2006 02:52:18 +0100 <1139017938.7984.52.camel@xpc.home.erwinrol.com> Message-ID: <20060204015959.1BE78180C28@magilla.sf.frob.com> > Does this ABI change cause random packages to break when doing "yum > update" in the next few days ? With other words would it be smart to > just wait until the complete rebuild is done before doing yum update > again ? The ABI is not changing for i386 or x86_64, but is for ppc and ppc64. The only things affected are uses of "long double", which are not very many. If there are uses in random libraries (gnome or whatnot) then such random packages may break on ppc/ppc64 between the time libraries are rebuilt and the time their dependent packages are rebuilt. Thanks, Roland From gilboad at gmail.com Sat Feb 4 01:44:40 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sat, 04 Feb 2006 03:44:40 +0200 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <20060204012809.GP24295@devserv.devel.redhat.com> References: <1139006387.2652.29.camel@bree.local.net> <43E3FF02.1060803@argo.co.il> <20060204012809.GP24295@devserv.devel.redhat.com> Message-ID: <1139017480.2918.60.camel@gilboa-home-dev.localhost> ... > 4) on i?86 and x86_64, -mtune=generic option has been added, which means > tuning for a pool of most commonly used CPUs. According to SPEC results > the code is no worse than -mtune={nocona,pentium4} used before on Intel > CPUs and is significantly better on AMD CPUs. > Yey! Opteron users rejoice! Gilboa From fcd-cornette at insight.rr.com Sat Feb 4 02:39:52 2006 From: fcd-cornette at insight.rr.com (Jim Cornette) Date: Fri, 03 Feb 2006 21:39:52 -0500 Subject: Replace mozilla with SeaMonkey? In-Reply-To: <43E38CEE.3080506@redhat.com> References: <20060203044733.AD2A173160@hormel.redhat.com> <43E38CEE.3080506@redhat.com> Message-ID: <43E413F8.7010201@insight.rr.com> Kai Engert wrote: > Jim Cornette wrote: > >> Would they use the same profile as Netscape 7 does? The query is >> mainly due to email accounts, bookmarks are rather large. I don't >> think needing to import all this information into another profile >> would be desirable. The different directories for Thunderbird and for >> mozilla are one feature that I do not care for. >> > Seamonkey uses the same profile in the same directory as the former > Mozilla 1.7.x suite. > > Kai > Thanks! I was fearing a Thunderbird type of change. I see no reason why one would devise separate profiles. Using the same directory/profile is what I want. I started using SeaMonkey instead of Mozilla for both Linux and windows. The mail, composer and browser worked the same or better than Mozilla. If Mozilla is replaced by SeaMonkey and is the only Suite maintained, I see no fallout from this type of change. Of course I'm seeing this from a user viewpoint. Applications that depend on Mozilla might disagree with this viewpoint. Jim -- It's the opinion of some that crops could be grown on the moon. Which raises the fear that it may not be long before we're paying somebody not to. -- Franklin P. Jones From fcd-cornette at insight.rr.com Sat Feb 4 03:10:14 2006 From: fcd-cornette at insight.rr.com (Jim Cornette) Date: Fri, 03 Feb 2006 22:10:14 -0500 Subject: Bad selinux policy? In-Reply-To: <6f27515e0602030508v57ea6a5cn@mail.gmail.com> References: <6f27515e0602022302j274040dbg@mail.gmail.com> <6f27515e0602030508v57ea6a5cn@mail.gmail.com> Message-ID: <43E41B16.7010805@insight.rr.com> MATSUURA Takanori wrote: > Dear all, > > Security contexts is rebuilt as the folloing and it recoverd. > Sorry for spam. > > 1. SELinux is disabled using system-config-securitylevel > 2. reboot > 3. SELinux is enforced using system-config-securitylevel > 4. reboot > > > MATSUURA Takanori > As far as I understand SELinux. If you have SELinux disabled, the file system does not write security content to the bits allocated for content by SELinux capable file systems. If you then enable SELinux, the security content has to be added to the files before your system is usable again. Changing from permissive to enforcing should not need a relabeling for security content. Permissive allows but logs errors and still labels files as enforcing mode does. You should use permissive instead of disabling SELinux unless you don't mind needing your system relabeled on reboot. Jim From jkeating at redhat.com Sat Feb 4 03:19:42 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 03 Feb 2006 19:19:42 -0800 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <1139017938.7984.52.camel@xpc.home.erwinrol.com> References: <1139006387.2652.29.camel@bree.local.net> <1139017938.7984.52.camel@xpc.home.erwinrol.com> Message-ID: <1139023182.13489.1.camel@ender> On Sat, 2006-02-04 at 02:52 +0100, Erwin Rol wrote: > > Since i was one (maybe even the only one ;-) that was complaining that > rawhide broke last time, I ask this now; > > Does this ABI change cause random packages to break when doing "yum > update" in the next few days ? With other words would it be smart to > just wait until the complete rebuild is done before doing yum update > again ? There will be a lot of churn over the next week. Broken deps, possibly broken apps, etc.. will happen. We do need people touching on the packages we do produce before Test3 so that these problems don't hit every user in test3. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From admin at ramshacklestudios.com Sat Feb 4 03:29:31 2006 From: admin at ramshacklestudios.com (Peter Gordon) Date: Fri, 03 Feb 2006 19:29:31 -0800 Subject: Xorg 6.9 Update for FC4? Message-ID: <1139023771.3267.8.camel@tuxhugger> Hi all. With the recent release of the modular X.org X11R7, will Fedora Core 4 receive an update to its monolithic counterpart X11R6.9? The primary reason I inquire about this is for the updated drivers. Every so often, OpenGL-intensive apps such as BZFlag and others will inevitably hardlock my system, forcing a reboot to fix it. Some games such as gl-117 refuse to even play without hardlocking. However, I upgraded a now-dead Gentoo install to one of the later X.org release candidates and found that, unlike 6.8 (both on Gentoo and Fedora), X11R7 seems to fix every issue that I have with the R200 driver. (I use a Radeon 9200.) While I'm aware that the shift to a modular, autotool build and distribution system is a very fundamental change to the architecture of X.org, it did put out a 6.9 release which is of the same codebase of 7.0, and thusly would (hopefully) also fix this and other small issues I have with the radeon driver. It would also provide better support for newer video cards (such as the i945 Intel GMA, R300-series Radeon cards, et al.) Also, I'm not aware of any difficulties that we would face in doing this. It would only be a matter of version-bumping the various xorg-x11 packages and building a new release, right? Alternatively, would it be better for me to grab a 6.9 source RPM and rebuild it for my FC4 system? If this is the preferred method by the Fedora X.org team, would someone please point me to instructions to do this? (Would it be a simple "rpm --rebuild xorg-x11*.src.rpm"?) Thanks for your time! -- Peter Gordon (codergeek42) GnuPG Public Key: 0xDA3634D7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mharris at mharris.ca Sat Feb 4 09:23:04 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Sat, 04 Feb 2006 04:23:04 -0500 Subject: propozition of specs cleanups In-Reply-To: <1138965417.25983.133.camel@kloczek01.pracownicy.zie> References: <1138959257.25983.84.camel@kloczek01.pracownicy.zie> <43E3302C.2070602@mharris.ca> <1138965417.25983.133.camel@kloczek01.pracownicy.zie> Message-ID: <43E47278.7090801@mharris.ca> Tomasz K?oczko wrote: [rude obnoxious comments removed] Welcome to my killfile. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From buildsys at redhat.com Sat Feb 4 09:23:45 2006 From: buildsys at redhat.com (Build System) Date: Sat, 4 Feb 2006 04:23:45 -0500 Subject: rawhide report: 20060204 changes Message-ID: <200602040923.k149Njh2004185@porkchop.devel.redhat.com> Updated Packages: acl-2.2.34-1 ------------ * Fri Feb 03 2006 Thomas Woerner 2.2.34-1 - new version 2.2.34 alsa-lib-1.0.11-3.rc2 --------------------- * Fri Feb 03 2006 Martin Stransky 1.0.11-3.rc2 - fix for #179446 - don't remove old SHM memory/keys during login anaconda-10.91.14-1 ------------------- * Fri Feb 03 2006 Jeremy Katz - 10.91.14-1 - Handle reiserfs labels (dcantrel, #125939) - Skip more steps in root mode (Jasper Hartline) - Update driver list for current kernels - Don't put mapper/ in the swap label (pjones) - Set file contexts on blkid.tab* (pjones) - Increase logical volume label field to 32 chars (dcantrel, #174661) - More exception trimming (clumens) - Fix args to writeConfiguration (clumens, #179928) - Fix format strings in label device, proper max for swap labels (pjones) - Make task definition more dynamic - Add a hack to remove the xen group if we're running on xen (#179387) attr-2.4.28-1 ------------- * Fri Feb 03 2006 Thomas Woerner 2.4.28-1 - new version 2.4.28 authconfig-5.2.0-1 ------------------ * Fri Feb 03 2006 Tomas Mraz - 5.2.0-1 - redesigned GUI (#178112) - added man page for system-config-ac (#179584) - disable authentication of system accounts by network services by default, added option for changing that (#179009) - updated translations, new languages control-center-1:2.13.90-2 -------------------------- * Fri Feb 03 2006 Christopher Aillon 1:2.13.90-2 - Patch gnome-about-me's file chooser dialog to default to the system faces directory eclipse-1:3.1.2-1jpp_2fc ------------------------ * Fri Feb 03 2006 Andrew Overholt 3.1.2-1jpp_2fc - Updated launcher script. emacs-21.4-12 ------------- * Fri Feb 03 2006 Jens Petersen - 21.4-12 - add mule-cmd.el-X11-locale.alias-173781.patch to correct location of X11 locale.alias file (Paul Dickson, #173781) - fix autoload of php-mode in php-mode-init.el (Christopher Beland, #179484) * Wed Dec 14 2005 Jens Petersen - 21.4-11 - avoid building with -fstack-protector on i386 to prevent crashing (Jonathan Kamens, #174730) - require xorg-x11-fonts-ISO8859-1-75dpi instead of xorg-x11-fonts-75dpi for modular X (#174614) emacspeak-23.0-1 ---------------- * Sat Feb 04 2006 Jens Petersen - 23.0-1 - update to 23.0 release - make package noarch - remove .cvsignore files - remove unnecessary playlists and file (Jef Spaleta, #177760) enscript-1.6.4-1.1 ------------------ * Fri Jan 27 2006 Jitka Kudrnacova 1.6.4-1.1 - fixed URL in the description (bug #178444) fontconfig-2.3.93.cvs20060131-3 ------------------------------- * Thu Feb 02 2006 Ray Strode - 2.3.93.cvs20060131-3 - Move user cache to a subdirectory (bug 160275) glibc-2.3.90-35 --------------- * Fri Feb 03 2006 Jakub Jelinek 2.3.90-35 - update from CVS - handle futimesat (fd, NULL, tvp) as futimes (fd, tvp) - fix q{e,f,g}cvt{,_r} for -mlong-double-64 gnome-games-1:2.13.6-3 ---------------------- * Sat Feb 04 2006 Matthias Clasen 1:2.13.6-3 - Remove unneeded gstreamer dependency gnome-user-share-0.9-2 ---------------------- * Fri Feb 03 2006 Alexander Larsson 0.9-2 - Patch config for apache 2.2 gnome-vfs2-2.13.4-7 ------------------- * Sat Feb 04 2006 Matthias Clasen 2.13.4-7 - Fix requires * Thu Jan 19 2006 Matthias Clasen 2.13.4-6 - Test build * Thu Jan 19 2006 Ray Strode 2.13.4-5 - s/sed -ie/sed -i -e/ grep-2.5.1-52 ------------- * Fri Feb 03 2006 Tim Waugh 2.5.1-52 - Prevent 'grep -P' from segfaulting (bug #171379). hplip-0.9.8-2 ------------- * Fri Feb 03 2006 Tim Waugh 0.9.8-2 - Patchlevel 2. * Thu Feb 02 2006 Tim Waugh 0.9.8-1 - 0.9.8. - No longer need initscript patch. - Don't package hpfax yet. httpd-2.2.0-5 ------------- * Fri Feb 03 2006 Joe Orton 2.2.0-5 - mod_ssl: add security fix for CVE-2005-3357 (#177914) - mod_imagemap: add security fix for CVE-2005-3352 (#177913) - add fix for AP_INIT_* designated initializers with C++ compilers - httpd.conf: enable HTMLTable in default IndexOptions - httpd.conf: add more "redirect-carefully" matches for DAV clients hwdata-0.174-1 -------------- * Wed Feb 01 2006 Phil Knirsch - 0.174-1 - Some cleanup and adds to the MonitorDB which closes several db related bugs. indent-2.2.9-12 --------------- * Thu Feb 02 2006 Petr Machata 2.2.9-12 - Adding Wei-Lun Chao's zh_TW UTF-8 messages (#134044) iptraf-3.0.0-1 -------------- * Fri Feb 03 2006 Miroslav Lichvar 3.0.0-1 - update to release 3.0.0 - spec cleanup - drop cfgpath patch - fix bad display of frames on linux console (#140698) kdeaccessibility-1:3.5.1-1 -------------------------- * Fri Feb 03 2006 Than Ngo 1:3.5.1-1 - 3.5.1 kdeaddons-3.5.1-1 ----------------- * Fri Feb 03 2006 Than Ngo 3.5.1-1 - 3.5.1 kdeadmin-7:3.5.1-1 ------------------ * Fri Feb 03 2006 Than Ngo 7:3.5.1-1 - 3.5.1 kdeartwork-3.5.1-1 ------------------ * Fri Feb 03 2006 Than Ngo 3.5.1-1 - 3.5.1 kdebase-6:3.5.1-2 ----------------- * Fri Feb 03 2006 Than Ngo 6:3.5.1-2 - apply patch to fix broken xx_XX layouts in kxkb - cleanup spec file kdegames-6:3.5.1-1 ------------------ * Fri Feb 03 2006 Than Ngo 6:3.5.1-1 - 3.5.1 kernel-2.6.15-1.1907_FC5 ------------------------ * Fri Feb 03 2006 Dave Jones - 2.6.16rc2 - Modify /etc/sysconfig/kernel on x86-64 to handle kernel-smp going away. - Silence noisy edac drivers. - Merge some patches from cpufreq git tree. - Fix some bogus percpu data accesses. - Suppress some network layer msgs kernel-xen-2.6.15-1.40_FC5 -------------------------- * Fri Feb 03 2006 Stephen Tweedie - Rebase to chrisw's latest merge tree (fix skbuff conflicts) - Rebase to xen-unstable hypervisor cset 8737 - Fix merge of davej's acpi changes to xen * Thu Feb 02 2006 Stephen Tweedie - Rebase to linux-2.6-merge.hg cset 19892 - Disable PAE again * Thu Feb 02 2006 Juan Quintela - merged with rawhide 1985. - enable PAE for this run. libXft-2.1.8.2-3 ---------------- * Thu Feb 02 2006 Mike A. Harris 2.1.8.2-3 - Added missing dependencies to devel subpackage to fix (#176744) man-pages-fr-0.9.7-13 --------------------- * Fri Feb 03 2006 Peter Vrabec - rebuilt * Tue Jan 10 2006 Bernd Groh - remove pages that conflict with shadow-utils mc-1:4.6.1a-7 ------------- * Wed Feb 01 2006 Jindrich Novy 4.6.1a-7 - update from CVS - fixes syntax file for PHP - make displaying of free space configurable - fix permission highlighting (#177100) - redirect stdout and stderr of several apps run on background to /dev/null to not to mess up mc interface (#178833) - refresh directories to avoid errors caused by copying files to non-existent directories (#177111) - add an option to insert changelog entry in mcedit, thanks to Radek Vokal mkinitrd-5.0.21-1 ----------------- * Fri Feb 03 2006 Peter Jones - 5.0.21-1 - add "mount -o bind" support and "mount --move" support (#109366, patch from Kasper Dupont) - add resolveDevice command, which cases down device labels. - remove "findlodev" from the documentation (#178587) - fix nash command name parsing bug (#178587) - fix "find" argument parsing (#178587) - add "find" handling for "-type d" * Thu Feb 02 2006 Peter Jones - 5.0.20-1 - fix really dumb spec file mistake - fix devno detection for /dev/root - fix testdm check * Thu Feb 02 2006 Peter Jones - 5.0.19-1 - mkinitrd: get resolve_dm_name() and get_numeric_dev() from initscripts instead of a private copy - add block.[ch]: - move parse_sysfs_devnum(), sysfs_blkdev_probe(), and mkpathbyspec() from nash.c - add label/uuid/name lookups for block devices using libblkid - add lib.[ch]: - move makeFdCoe(), coeOpen(), coeFopen(), coeOpendir(), readFD(), nashLoggerV(), nashLogger(), qprintf(), eprintf(), smartmknod(), testing, quiet, reallyquiet from nash.c - move nashDefaultLogger(), from dm.c - move log enums and declarations from dm.h - dm.c: add dm_finish(), which does dm_task_destroy() and then library cleanup (solves an fd leak) - remove linux_fs.h, mount_by_label.[ch], name_to_dev_t.[ch] notify-daemon-0.3.1-6 --------------------- * Fri Feb 03 2006 Christopher Aillon - 0.3.1-6 - Add patch to determine whether a compositing manager is running when drawing a new notification bubble, as long as the CM grabs the appropriate XSelection. pam-0.99.3.0-1 -------------- * Fri Feb 03 2006 Tomas Mraz 0.99.3.0-1 - new upstream version - updated db4 to 4.3.29 - added module pam_tally2 with auditing support - added manual pages for system-auth and config-util (#179584) * Tue Jan 03 2006 Tomas Mraz 0.99.2.1-3 - remove 'initscripts' dependency (#176508) - update pam-redhat modules, merged patches * Fri Dec 16 2005 Tomas Mraz 0.99.2.1-2 - fix dangling symlinks in -devel (#175929) - link libaudit only where necessary - actually compile in audit support perl-4:5.8.8-1.1 ---------------- * Fri Feb 03 2006 Jason Vas Dias - 4:5.8.8-1.1 - Rebuild with new gcc and glibc * Wed Feb 01 2006 Jason Vas Dias - 4:5.8.8-1 - Upgrade to new upstream release 5.8.8, officially released today * Tue Jan 31 2006 Jason Vas Dias - 3:5.8.8-0.1_RC1 - fix bug 178343: h2ph must include cpp "predefined macros" in _h2ph_pre.ph - Add perl(:MODULE_COMPAT_5.8.8) to Provides - Fix perlbug patch perl-Archive-Tar-1.28-1 ----------------------- * Thu Feb 02 2006 Jason Vas Dias - 1.28-1 - Upgrade to upstream version 1.28 - Rebuild for perl-5.8.8 perl-Archive-Zip-1.16-1.2 ------------------------- * Fri Feb 03 2006 Jason Vas Dias - 1.16-1.2 - rebuilt for new perl-5.8.8 perl-BSD-Resource-1.24-3.2 -------------------------- * Fri Feb 03 2006 Jason Vas Dias - 1.24-3.2 - rebuild for new perl-5.8.8 perl-Bit-Vector-6.4-2.2 ----------------------- * Fri Feb 03 2006 Jason Vas Dias - 6.4-2.2 - rebuild for new perl-5.8.8 perl-Carp-Clan-5.3-1.2 ---------------------- perl-Compress-Zlib-1.41-1.2 --------------------------- * Fri Feb 03 2006 Jason Vas Dias - 1.41-1.2 - rebuild for new perl-5.8.8 perl-Convert-ASN1-0.19-1.2 -------------------------- * Fri Feb 03 2006 Jason Vas Dias - 1.19-1.2 - rebuild for new perl-5.8.8 perl-Crypt-SSLeay-0.51-9.2 -------------------------- * Fri Feb 03 2006 Jason Vas Dias - 0.51-9.2 - rebuild for new perl-5.8.8 / gcc / glibc perl-DBD-MySQL-3.0002-2.2 ------------------------- * Fri Feb 03 2006 Jason Vas Dias - 3.0002-2.2 - rebuild for new perl-5.8.8 perl-DBD-Pg-1.43-2.2 -------------------- * Fri Feb 03 2006 Jason Vas Dias - 1.43-2.2 - rebuild for new perl-5.8.8 perl-DBI-1.50-2 --------------- * Fri Feb 03 2006 Jason Vas Dias - 1.50-2 - rebuild for new perl-5.8.8 / gcc / glibc perl-Date-Calc-5.4-1.2 ---------------------- * Fri Feb 03 2006 Jason Vas Dias - 5.4-1.2 - rebuild for new perl-5.8.8 perl-DateManip-5.44-1.2 ----------------------- * Fri Feb 03 2006 Jason Vas Dias - 5.44-1.2 - rebuild for new perl-5.8.8 perl-Devel-Symdump-2.06-1 ------------------------- * Fri Feb 03 2006 Jason Vas Dias - 2.06-1 - Upgrade to 2.0.6 - rebuild for new perl-5.8.8 perl-Digest-HMAC-1.01-14.2 -------------------------- * Fri Feb 03 2006 Jason Vas Dias - 1.01-14.2 - rebuild for new perl-5.8.8 perl-Digest-SHA1-2.11-1 ----------------------- * Fri Feb 03 2006 Jason Vas Dias - 2.11-1 - Upgrade to 2.11 - rebuild for new perl-5.8.8 perl-File-MMagic-1.26-1 ----------------------- * Fri Feb 03 2006 Jason Vas Dias - 1.26-1 - Upgrade to 1.26 - rebuild for new perl-5.8.8 perl-Frontier-RPC-0.06-39.2 --------------------------- * Fri Feb 03 2006 Jason Vas Dias - 0.06-39.2 - rebuild for new perl-5.8.8 perl-HTML-Parser-3.48-1.1 ------------------------- * Fri Feb 03 2006 Jason Vas Dias - 3.48-1 - rebuild for new perl-5.8.8 perl-HTML-Tagset-3.10-2.1 ------------------------- * Fri Feb 03 2006 Jason Vas Dias - 3.10-2.1 - rebuild for new perl-5.8.8 perl-IO-String-1.08-1.1 ----------------------- * Fri Feb 03 2006 Jason Vas Dias - 0:1.08-1.1 - rebuild for new perl-5.8.8 perl-IO-Zlib-1.04-4.2 --------------------- * Fri Feb 03 2006 Jason Vas Dias - 1.04-4.2 - rebuild for new perl-5.8.8 perl-Inline-0.44-15.2 --------------------- * Fri Feb 03 2006 Jason Vas Dias - 0.44-15.2 - rebuild for new perl-5.8.8 perl-LDAP-1:0.33-1.2 -------------------- * Fri Feb 03 2006 Jason Vas Dias - 0.33-1.2 - rebuild for new perl-5.8.8 perl-Net-DNS-0.55-1.1 --------------------- * Fri Feb 03 2006 Jason Vas Dias - 0.55-1.1 - rebuild for new perl-5.8.8 perl-Net-IP-1.24-2.2 -------------------- * Fri Feb 03 2006 Jason Vas Dias - 1.24-2.2 - rebuild for new perl-5.8.8 perl-Net-Telnet-3.03-4.2 ------------------------ * Fri Feb 03 2006 Jason Vas Dias - 3.03-4.2 - rebuild for new perl-5.8.8 - modify .spec file to conform to Fedora spectemplate-perl.spec perl-PDL-2.4.2-2.fc5.1.2 ------------------------ * Fri Feb 03 2006 Jason Vas Dias - 2.4.2-2.fc5.1.2 - rebuild for new perl-5.8.8 - enable build to succeed without perl-PDL being installed :-) perl-Parse-RecDescent-1.94-5.2 ------------------------------ * Fri Feb 03 2006 Jason Vas Dias - 1.94-5.2 - rebuild for new perl-5.8.8 perl-RPM-Specfile-1.19-2.1 -------------------------- * Fri Feb 03 2006 Jason Vas Dias - 1.19-2.1 - rebuild for new perl-5.8.8 perl-SGMLSpm-1.03ii-16.2 ------------------------ * Fri Feb 03 2006 Jason Vas Dias - 1.03ii-16.2 - rebuild for new perl-5.8.8 perl-String-CRC32-1.3-3.FC5 --------------------------- * Fri Feb 03 2006 Jason Vas Dias - 0:1.03-3.FC5 - rebuild for new perl-5.8.8 perl-TermReadKey-2.30-1.2 ------------------------- * Fri Feb 03 2006 Jason Vas Dias - 2.30-1.2 - rebuild for new perl-5.8.8 perl-TimeDate-1:1.16-3.2 ------------------------ * Fri Feb 03 2006 Jason Vas Dias - 1:1.16-3.2 - rebuild for new perl-5.8.8 perl-URI-1.35-2.2 ----------------- * Fri Feb 03 2006 Jason Vas Dias - 1.35-2.2 - rebuild for new perl-5.8.8 perl-XML-Dumper-0.79-1.2 ------------------------ * Fri Feb 03 2006 Jason Vas Dias - 0.79-1.2 - rebuild for new perl-5.8.8 perl-XML-Grove-0.46alpha-29.1 ----------------------------- * Fri Feb 03 2006 Jason Vas Dias - 0.46alpha-29.1 - rebuild for new perl-5.8.8 perl-XML-LibXML-1.58-2.2 ------------------------ * Fri Feb 03 2006 Jason Vas Dias - 1.58-2.2 - rebuild for new perl-5.8.8 perl-XML-LibXML-Common-0.13-8.2 ------------------------------- * Fri Feb 03 2006 Jason Vas Dias - 0.13-8.2 - rebuild for new perl-5.8.8 perl-XML-NamespaceSupport-1.09-1.2 ---------------------------------- * Fri Feb 03 2006 Jason Vas Dias - 1.09-1.2 - rebuild for new perl-5.8.8 perl-XML-Parser-2.34-6.1.2 -------------------------- * Fri Feb 03 2006 Jason Vas Dias - 2.34-6-1.2 - rebuild for new perl-5.8.8 perl-XML-SAX-0.13-1.1 --------------------- * Fri Feb 03 2006 Jason Vas Dias - 0.13-1.1 - rebuild for new perl-5.8.8 * Mon Dec 19 2005 Jason Vas Dias - 0.13-1 - upgrade to 0.13 * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcc perl-XML-Simple-2.14-2.1 ------------------------ * Fri Feb 03 2006 Jason Vas Dias - 2.14-2.1 - rebuild for new perl-5.8.8 perl-XML-Twig-3.23-1 -------------------- * Fri Feb 03 2006 Jason Vas Dias - 3.22-1.1 - Update to 3.23 - rebuild for new perl-5.8.8 perl-libwww-perl-5.805-1.1 -------------------------- * Fri Feb 03 2006 Jason Vas Dias - 5.805-1.1 - rebuild for new perl-5.8.8 perl-libxml-perl-0.08-1.2 ------------------------- * Fri Feb 03 2006 Jason Vas Dias - 0.08-1.2 - rebuild for new perl-5.8.8 pirut-0.9.10-1 -------------- * Sat Feb 04 2006 Jeremy Katz - 0.9.10-1 - Add a popup menu for selecting all/none of the optional packages in a group - Speed up pirut startup and list mode a bit * Fri Feb 03 2006 Jeremy Katz - 0.9.9-1 - Just use the group name when we don't have a description (#178089) - Require actually clicking on the checkboxes, not the text (#178090) - Make browse view a little bit more obvious (#178091) - Fix selection in list filters (#179210) - Fix searching in list view (#179839) - Fix searching in optional packages list - Allow unsigned packages with a suitably scary warning on installing single packages (#178908) policycoreutils-1.29.18-2 ------------------------- * Fri Feb 03 2006 Dan Walsh 1.29.18-2 - Add auditing to semanage postgresql-odbc-08.01.0200-1 ---------------------------- * Fri Feb 03 2006 Tom Lane 08.01.0200-1 - Update to version 08.01.0200. - Upstream now calls the library psqlodbcw.so ... add a symlink to avoid breaking existing odbc configuration files. pychecker-0.8.17-1 ------------------ * Sat Feb 04 2006 Miloslav Trmac - 0.8.17-1 - Update to pychecker-0.8.17 redhat-rpm-config-8.0.40-1 -------------------------- * Fri Feb 03 2006 Jeremy Katz - 8.0.40-1 - use -mtune=generic for x86 and x86_64 * Tue Aug 16 2005 Elliot Lee - 8.0.39-1 - Fix #165416 * Mon Aug 01 2005 Elliot Lee - 8.0.38-1 - Add -Wall into cflags scim-1.4.4-2 ------------ * Fri Feb 03 2006 Jens Petersen - 1.4.4-2 - remove scim-reload-engines-165655.patch since it seems to break input after reloading configuration (#179807) - add gtkimm-clear-preedit-on-reset-174143.patch to clear the preedit buffer when IME turned off (Qian Shen, #174143) - add rawcode-unicode-maxlength.patch to improve input of unicode codes (James Su, #173102) - add scim.pc-versioned-moduledir-179706.patch to include api version in moduledir in scim.pc so that IMEs get installed in versioned dir by default (Akira Tagoh, #179706) * Fri Jan 13 2006 Jens Petersen - 1.4.4-1 - update to 1.4.4 bugfix release - scim-gtk-langs-167090.patch no longer needed since 1.4.3 - move scim dl modules to scim-libs for multilib to work correctly - define %scim_api * Mon Dec 19 2005 Jens Petersen - 1.4.2-9 - enable linker symbol versioning now that mt_alloc is fixed (#173220) - buildrequire libXt-devel for configure - buildrequire autoconf, automake, and libtool for autoreconf selinux-policy-2.2.11-1 ----------------------- * Fri Feb 03 2006 Dan Walsh 2.2.11-1 - Fixes for mcs - Turn on mount and fsadm for unconfined_t * Wed Feb 01 2006 Dan Walsh 2.2.10-1 - Fixes for the -devel package system-config-kickstart-2.6.4-1 ------------------------------- * Fri Feb 03 2006 Chris Lumens 2.6.4-1 - Convert package selection to using pirut (#178759). - Partitioning screen fixes for cciss. - Use consolehelper. system-config-lvm-1.0.11-1.0 ---------------------------- * Fri Feb 03 2006 Stanko Kupcevic 1.0.11-1.0 - Fixes for bz175077,169860,178128,161917,171117,175131,178195 tomcat5-0:5.0.30-8jpp_9fc ------------------------- * Wed Feb 01 2006 Rafael Schloming - 0:5.0.30-8jpp_9fc - Fixed XSS vulnerabilities in the example apps. xorg-x11-drv-ati-6.5.7.3-2 -------------------------- * Thu Feb 02 2006 Mike A. Harris 6.5.7.3-2 - Added r128.xinf and radeon.xinf videoalias files to fix bug (#174101). - Added "BuildRequires: libdrm-devel >= 2.0-1" to fix bug (#178613) xorg-x11-drv-dummy-0.1.0.5-1 ---------------------------- * Wed Jan 18 2006 Mike A. Harris 0.1.0.5-1 - Updated xorg-x11-drv-dummy to version 0.1.0.5 from X11R7.0 xorg-x11-drv-glint-1.0.1.3-1 ---------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.1.3-1 - Updated xorg-x11-drv-glint to version 1.0.1.3 from X11R7.0 xorg-x11-drv-i740-1.0.0.5-1 --------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-i740 to version 1.0.0.5 from X11R7.0 xorg-x11-drv-i810-1.4.1.3-2 --------------------------- * Fri Feb 03 2006 Mike A. Harris 1.4.1.3-2 - Added 8086:2592 mapping to i810.xinf for bug (#172884) * Wed Jan 18 2006 Mike A. Harris 1.4.1.3-1 - Updated xorg-x11-drv-i810 to version 1.4.1.3 from X11R7.0 xorg-x11-drv-mga-1.2.1.3-1 -------------------------- * Wed Jan 18 2006 Mike A. Harris 1.2.1.3-1 - Updated xorg-x11-drv-mga to version 1.2.1.3 from X11R7.0 xorg-x11-drv-neomagic-1.0.0.5-1 ------------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-neomagic to version 1.0.0.5 from X11R7.0 xorg-x11-drv-nsc-2.7.6.5-2 -------------------------- * Fri Feb 03 2006 Mike A. Harris 2.7.6.5-2 - Added nsc.xinf driver mapping file. * Wed Jan 18 2006 Mike A. Harris 2.7.6.5-1 - Updated xorg-x11-drv-nsc to version 2.7.6.5 from X11R7.0 xorg-x11-drv-nv-1.0.1.5-1 ------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.1.5-1 - Updated xorg-x11-drv-nv to version 1.0.1.5 from X11R7.0 xorg-x11-drv-rendition-4.0.1.3-1 -------------------------------- * Wed Jan 18 2006 Mike A. Harris 4.0.1.3-1 - Updated xorg-x11-drv-rendition to version 4.0.1.3 from X11R7.0 xorg-x11-drv-s3-0.3.5.5-1 ------------------------- * Wed Jan 18 2006 Mike A. Harris 0.3.5.5-1 - Updated xorg-x11-drv-s3 to version 0.3.5.5 from X11R7.0 xorg-x11-drv-s3virge-1.8.6.5-1 ------------------------------ * Wed Jan 18 2006 Mike A. Harris 1.8.6.5-1 - Updated xorg-x11-drv-s3virge to version 1.8.6.5 from X11R7.0 xorg-x11-drv-savage-2.0.2.3-1 ----------------------------- * Wed Jan 18 2006 Mike A. Harris 2.0.2.3-1 - Updated xorg-x11-drv-savage to version 2.0.2.3 from X11R7.0 xorg-x11-drv-sis-0.8.1.3-1 -------------------------- * Wed Jan 18 2006 Mike A. Harris 0.8.1.3-1 - Updated xorg-x11-drv-sis to version 0.8.1.3 from X11R7.0 * Tue Dec 20 2005 Mike A. Harris 0.8.1.2-1 - Updated xorg-x11-drv-sis to version 0.8.1.2 from X11R7 RC4 - Removed 'x' suffix from manpage dirs to match RC4 upstream. * Wed Nov 16 2005 Mike A. Harris 0.8.1-1 - Updated xorg-x11-drv-sis to version 0.8.1 from X11R7 RC2 - Added "BuildRequires: mesa-libGL-devel >= 6.4-4" for DRI-enabled builds. xorg-x11-drv-tdfx-1.1.1.3-1 --------------------------- * Wed Jan 18 2006 Mike A. Harris 1.1.1.3-1 - Updated xorg-x11-drv-tdfx to version 1.1.1.3 from X11R7.0 xorg-x11-drv-trident-1.0.1.2-1 ------------------------------ * Wed Jan 18 2006 Mike A. Harris 1.0.1.2-1 - Updated xorg-x11-drv-trident to version 1.0.1.2 from X11R7.0 xorg-x11-drv-tseng-1.0.0.5-1 ---------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-tseng to version 1.0.0.5 from X11R7.0 xorg-x11-drv-v4l-0.0.1.5-1 -------------------------- * Wed Jan 18 2006 Mike A. Harris 0.0.1.5-1 - Updated xorg-x11-drv-v4l to version 0.0.1.5 from X11R7.0 xorg-x11-drv-vesa-1.0.1.3-1 --------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.1.3-1 - Updated xorg-x11-drv-vesa to version 1.0.1.3 from X11R7.0 xorg-x11-drv-vga-4.0.0.5-1 -------------------------- * Wed Jan 18 2006 Mike A. Harris 4.0.0.5-1 - Updated xorg-x11-drv-vga to version 4.0.0.5 from X11R7.0 xorg-x11-drv-via-0.1.33.2-1 --------------------------- * Wed Jan 18 2006 Mike A. Harris 0.1.33.2-1 - Updated xorg-x11-drv-via to version 0.1.33.2 from X11R7.0 xorg-x11-drv-vmware-10.11.1.3-1 ------------------------------- * Wed Jan 18 2006 Mike A. Harris 10.11.1.3-1 - Updated xorg-x11-drv-vmware to version 10.11.1.3 from X11R7.0 xorg-x11-drv-voodoo-1.0.0.5-1 ----------------------------- * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-voodoo to version 1.0.0.5 from X11R7.0 yum-2.5.1-4 ----------- * Fri Feb 03 2006 Paul Nasrat - 2.5.1-4 - Fix group unselect traceback (cf #177737) Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- ccs-devel - 1.0.2-3.1.ppc requires ccs = 0:1.0.2-3.1 gulm - 1.0.4-2.FC5.1.ppc requires ccs Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.4-2.s390 requires kernel >= 0:2.6.9-11 Broken deps for s390x ---------------------------------------------------------- libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) systemtap - 0.5.4-2.s390x requires kernel >= 0:2.6.9-11 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 From mharris at mharris.ca Sat Feb 4 09:27:16 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Sat, 04 Feb 2006 04:27:16 -0500 Subject: Upgrade from old X packages with /usr/X11R6/bin/mkfontdir in %postun In-Reply-To: <20060203135922.7e410939@python2> References: <20060203135922.7e410939@python2> Message-ID: <43E47374.40403@mharris.ca> Matthias Saou wrote: > Hi, > > I just ran "yum update" on an FC4 machine to bring it up to date with > Rawhide to do some testing and ran into a few quirks. > > One was VNC's scriplet : > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179849 > > Then, much more tricky... not sure if it's even worth bugzilla'ing since > it's clearly a dead end :-( > > Removing : fonts-xorg-ISO8859-15-100dpi ##################### [708/835] > /var/tmp/rpm-tmp.7625: line 3: /usr/X11R6/bin/mkfontdir: No such file or > directory error: %postun(fonts-xorg-ISO8859-15-100dpi-6.8.2-1.noarch) > scriptlet failed, exit status 127 > > Removing : fonts-xorg-75dpi ##################### [655/835] > /var/tmp/rpm-tmp.29316: line 3: /usr/X11R6/bin/mkfontdir: No such file or > directory error: %postun(fonts-xorg-75dpi-6.8.2-1.noarch) scriptlet > failed, exit status 127 > > For those packages' %postun, the stuff in /usr/X11R6/bin/ is obviously > gone now, so the failure is expected... and I can't think of any way to > sanely fix that. > > The result is that those packages don't get erased from the local rpm > database... > > Any brilliant ideas? (apart from symlinking stuff in /usr/X11R6/bin/ for > FC5...) Yeah, that's kindof ugly. The only foolproof way I can think of handling this, is to have compatibility symlinks in the mkfontdir package in /usr/X11R6/bin. If anyone has alternative ideas for a reasonable solution though, I'm open to ideas. If nothing else comes up as a viable solution however, I'll probably stick some backward compatible symlinks into the packaging prior to FC5 though, as I think we do need to cover this at least for a few OS releases. Also, since FC is the basis for RHEL, the back-compat stuff probably needs to stick around longer than I'd prefer to have it stick around. That can be handled separately for RHEL though too.. Suggestions appreciated. TIA -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Sat Feb 4 10:06:19 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Sat, 04 Feb 2006 05:06:19 -0500 Subject: Xorg 6.9 Update for FC4? In-Reply-To: <1139023771.3267.8.camel@tuxhugger> References: <1139023771.3267.8.camel@tuxhugger> Message-ID: <43E47C9B.8040806@mharris.ca> Peter Gordon wrote: > Hi all. > > With the recent release of the modular X.org X11R7, will Fedora Core 4 receive > an update to its monolithic counterpart X11R6.9? Fedora Core 4 will most likely remain at Xorg 6.8.2, however we have at least considered what you're suggesting. Engineering has been focusing entirely on FC5 and RHEL for the most part for a while now, which will probably continue through the remainder of the FC5 devel cycle. There will likely be some FC4 X updates yet to come, but barring critical security issues, bugfixes and driver updates for FC4 wont happen likely until FC5 is released, mainly due to resource constraints. Having said that though, there are a growing number of issues in FC4's X, which I would like to address in the next non-security triggered update for FC4, including the new backport of the 'nv' driver from X11R7. I'd also like to sync all RHEL4 bugfixes into the next FC4 X update too, among other things. A 6.9 update however, is not on the radar for FC4, at least with our current schedules. I may suggest it in our team meeting again in the future though, but no promises. > The primary reason I inquire about this is for the updated drivers. Every so > often, OpenGL-intensive apps such as BZFlag and others will inevitably hardlock > my system, forcing a reboot to fix it. Some games such as gl-117 refuse to even > play without hardlocking. However, I upgraded a now-dead Gentoo install to one > of the later X.org release candidates and found that, unlike 6.8 (both on Gentoo > and Fedora), X11R7 seems to fix every issue that I have with the R200 driver. > (I use a Radeon 9200.) I can neither agree or disagree with that, as I really done similar comparisons between the two, however at the current point in time at least, X11R7 is quite a bit less stable than 6.8.2 is overall. R7 needs a fair amount more stabilization yet. > While I'm aware that the shift to a modular, autotool build and distribution > system is a very fundamental change to the architecture of X.org, it did put out > a 6.9 release which is of the same codebase of 7.0, and thusly would (hopefully) > also fix this and other small issues I have with the radeon driver. It would > also provide better support for newer video cards (such as the i945 Intel GMA, > R300-series Radeon cards, et al.) Releasing modular X for FC4 is definitely out of the question for sure, as it inflicts a large number of changes into the system when done in the context of an "official" OS update. It would require releasing a great many updates to other packages to keep the system clean. Far too many to really be considered in "official" context. Having said that however, I run modular X from FC5 rebuild on my FC4 system locally and it works fine. I dont mind the fact there are some dependency conflicts, and that half the FC4 packages wont compile cleanly on top of the modular X packaging without changes though. So it works fine in "unofficial" context, but is not polished enough distro-wide for consideration for official packages released to the public. X11R6.9 is the same source code of course, and while that is theoretically possible, a number of factors would need to be considered very carefully. I'm not opposed to it personally, but having had to make decisions like this for 5+ years now across about 12 OS releases, I have a good gut feeling for when we need to be very careful about updating certain things. ;o) For now, I wouldn't say "yes", but I wouldn't say "no" either. It's currently more of a "lets wait and see how X11R7 stabilizes first" type of thing. Once that happens, if it appears we have engineering resources available that could be allocated to doing it, I may bring it up with the team again and see what team concensus seems to be. With FC5 coming out very very soon however, another factor is wether it is even worth spending the time and effort on doing the work for FC4. With fixed engineering manpower, 1 hour of work spent on FC4, is an hour of work directly taken from fixing bugs on FC5. That's very important to consider also. > Also, I'm not aware of any difficulties that we would face in doing this. It > would only be a matter of version-bumping the various xorg-x11 packages and > building a new release, right? A 6.9 release would be a lot more work than that, but much much less work than doing a 7.0 release. I already have 6.9 beta rpms which I could probably update cleanly to 6.9 in a day or two, which would then need a few weeks of cleaning up and bugfixing, etc. I may do that at some point anyway, wether or not we release it for FC4 officially. It'd be nice to have it as unofficial packages for people who are interested, and it would help get the code more tested, however everyone has to realize that 6.9 is very _dead_ code now. The monolithic Xorg CVS is frozen now. > Alternatively, would it be better for me to grab a 6.9 source RPM and rebuild it > for my FC4 system? If this is the preferred method by the Fedora X.org team, > would someone please point me to instructions to do this? (Would it be a simple > "rpm --rebuild xorg-x11*.src.rpm"?) There are a few people who have produced Xorg 6.8.99.x and possibly 6.9 rpms out there. The ones I have seen were initially based upon the FC4 packages, or upon 6.8.99.x packages that I created a while back, however since the people who made them were making them for themselves first to scratch a personal itch, I found they included too many experimental patches and changes to the packaging. They'd probably be ok to use on noncritical systems, knowing of course that they may contain highly experimental bits. If there is strong enough interest in 6.9 rpms, I might be able to be convinced to spend some of my personal time updating my previous 6.8.99.x packages on the weekend sometime. Of course it has to be a pleasant experience for me to expend the effort though. The last time I did it, the feedback I got from people was mostly inflammatory and negative, with no appreciation for the effort, so I stopped doing it. For an example of what I mean by this, simply look back a few messages in this list to discover how rude and thankless people can sometimes be. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From kloczek at zie.pg.gda.pl Sat Feb 4 10:31:20 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=) Date: Sat, 04 Feb 2006 11:31:20 +0100 Subject: propozition of specs cleanups In-Reply-To: <43E47278.7090801@mharris.ca> References: <1138959257.25983.84.camel@kloczek01.pracownicy.zie> <43E3302C.2070602@mharris.ca> <1138965417.25983.133.camel@kloczek01.pracownicy.zie> <43E47278.7090801@mharris.ca> Message-ID: <1139049080.6900.3.camel@kloczek01.pracownicy.zie> Dnia 04-02-2006, sob o godzinie 04:23 -0500, Mike A. Harris napisa?(a): > Tomasz K?oczko wrote: > > [rude obnoxious comments removed] > > Welcome to my killfile. $ rpm -qf /usr/share/aclocal /usr/share /usr/bin /usr/lib 2>&1 | grep -v filesystem | grep -v automake| wc -l 64 So you want say fixing cases like above realy requires 65 separated bugzilla BR ? or maybe all xorg packages are realy perfect ? kloczek From sundaram at fedoraproject.org Sat Feb 4 10:44:29 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 04 Feb 2006 16:14:29 +0530 Subject: propozition of specs cleanups In-Reply-To: <1139049080.6900.3.camel@kloczek01.pracownicy.zie> References: <1138959257.25983.84.camel@kloczek01.pracownicy.zie> <43E3302C.2070602@mharris.ca> <1138965417.25983.133.camel@kloczek01.pracownicy.zie> <43E47278.7090801@mharris.ca> <1139049080.6900.3.camel@kloczek01.pracownicy.zie> Message-ID: <43E4858D.9090604@fedoraproject.org> Tomasz K?oczko wrote: >Dnia 04-02-2006, sob o godzinie 04:23 -0500, Mike A. Harris napisa?(a): > > >>Tomasz K?oczko wrote: >> >>[rude obnoxious comments removed] >> >>Welcome to my killfile. >> >> > >$ rpm -qf /usr/share/aclocal /usr/share /usr/bin /usr/lib 2>&1 | grep >-v filesystem | grep -v automake| wc -l >64 > >So you want say fixing cases like above realy requires 65 separated >bugzilla BR ? > Thats one way of doing it. > or maybe all xorg packages are realy perfect ? > > Nothing is perfect. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From sundaram at fedoraproject.org Sat Feb 4 10:57:28 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 04 Feb 2006 16:27:28 +0530 Subject: propozition of specs cleanups In-Reply-To: <1138985448.25983.182.camel@kloczek01.pracownicy.zie> References: <1138959257.25983.84.camel@kloczek01.pracownicy.zie> <43E3302C.2070602@mharris.ca> <1138965417.25983.133.camel@kloczek01.pracownicy.zie> <43E34156.9030402@fedoraproject.org> <1138968719.25983.142.camel@kloczek01.pracownicy.zie> <43E34B61.9000809@fedoraproject.org> <1138985448.25983.182.camel@kloczek01.pracownicy.zie> Message-ID: <43E48898.1040201@fedoraproject.org> Hi >Sorry but my rude expression it is reaction on submiting many separated >BR via bugzilla for *very* small changes in many packages. > > It doesnt require showing poor attitude. Keep the discussion technical. >There is no leader in fedora development team or someone other hwo watch >on all traffic in CVS or other persons who can commit some mainly >stylistics changes ? If no .. look on current form od FC spec files. So >many styles as many developers. This it makes much more harder for any >developers .. this is like idendenting .c files. > > It is rarely possible for anyone to watch all the traffic in any list in Fedora much less all the CVS changes in a thorough fashion to "standardize" spec files . What would be better is to enforce packaging guidelines and review each of the packages when they are introduced. Thats what is being done in Fedora Extras. >If you want more I have *very long* list of this kind things. but IMO >best will be introduce all this one by one for aprove and inform in best >possible way all developers about some common rules on maintainig specs. > > Doing it piecemeal is not going to be worth the effort for you or for the developers without a consensus. So since you have a long list of similar things, it would be better to write one solid proposal for all the changes that you believe needs standardization and send it to the list so that developers can reach consensus on it and follow those guidelines. Kindly refer to http://fedoraproject.org/wiki/Packaging/Guidelines for existing guidelines. >Do you see now most of this kind changes can be performed by single >perl/sed regexp ? if yes .. ask: why the hell for change N single line >cleanups in N spec files must be involved N developers ? this single >change and require single developer who can commit this with aprove all >other developers. > >IMO best way for introduce this kind changes will be make propozition of >this kind changes (one by one or in small groups) for discuss -> after >pass few days for discuss and without protests -> performe single commit >by someon who have permission for this kind stylistics/cosmetics changes >for making this like "shoot and forget" without absorbe each developer >for making each single line/small adjustment. > >Ones more: I'm not talking about bugs or critical bugs. I'm talking >about prepare some kind of "common spec coding style". >If introducing this kind chanes will be possible only via bugzilla for >each package this will create unnormal amout of traffic in bugzill wich >can stop many people for many days or weeks. Do you see this now ? > > Your idea is much more explicit and clear now. See above for my comments. > > >>>If you want my time for spending on bugzilla -> please pay me for this >>>(sorry) or show me how can I introduce in time frame comparable to time >>>spend on thinking on sed line >>> >>> >>> >>> >>It probably can be done within the buildsystem to enforce such things. >>Meanwhile if you dont want to voluntarily spend the time involved in >>reporting this changes to the individual developers through bugzilla >>feel free to drop it but several people have done similar things before. >> >> > >Hanging this in build system is bad point. >This will be like indenting .c files on compile stage. > > Depends on how you do it. You can enforce code standards in a build system in different ways. It is automated and likely to be more comprehensive and efficient especially for repetitive tasks. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From mailinglists at erwinrol.com Sat Feb 4 11:13:33 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sat, 04 Feb 2006 12:13:33 +0100 Subject: Java bug status Message-ID: <1139051613.2795.4.camel@xpc.home.erwinrol.com> What is the status of this highly annoying bug that prevents about every java application from working ? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179228 The priority of this bug is just "normal" but since it breaks a lot of software (and if it is a kernel issue, it breaks maybe even more than just the java software) shouldn't its priority be "high" ? - Erwin From igorm5 at vip.hr Sat Feb 4 11:19:57 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Sat, 04 Feb 2006 12:19:57 +0100 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <1139014200.2863.65.camel@yoda.loki.me> References: <1139006387.2652.29.camel@bree.local.net> <43E3F78C.8030602@vip.hr> <1139014200.2863.65.camel@yoda.loki.me> Message-ID: <43E48DDD.4060508@vip.hr> Jesse Keating wrote: > On Sat, 2006-02-04 at 01:38 +0100, Igor Jagec wrote: >>Well, I suppose that FC5 final is going to be released somewhere about >>my birthday (26th of March)... it's going to be a very nice birthday >>gift thoe ;) > My birthday being the 13th of march means that I'll be working very hard My girlfriend has birthday on 13th of March, no kidding :))) We can celebrate all the birthdays together if you come visit Croatia until then ;) > during that time to make sure FC5 is a great release for YOUR birthday > (; It's gonna be a great release. It's been a long time since FC4 was released... I suppose that RHEL5 will be based on FC5 since it took as much time to build it. Maybe it is a good idea to make release cycle to one year instead of 4 to 6 months as it is said it's going to be for Fedora Core. -- Igor Jagec From kloczek at zie.pg.gda.pl Sat Feb 4 11:28:16 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=) Date: Sat, 04 Feb 2006 12:28:16 +0100 Subject: propozition of specs cleanups In-Reply-To: <43E48898.1040201@fedoraproject.org> References: <1138959257.25983.84.camel@kloczek01.pracownicy.zie> <43E3302C.2070602@mharris.ca> <1138965417.25983.133.camel@kloczek01.pracownicy.zie> <43E34156.9030402@fedoraproject.org> <1138968719.25983.142.camel@kloczek01.pracownicy.zie> <43E34B61.9000809@fedoraproject.org> <1138985448.25983.182.camel@kloczek01.pracownicy.zie> <43E48898.1040201@fedoraproject.org> Message-ID: <1139052496.6900.29.camel@kloczek01.pracownicy.zie> Dnia 04-02-2006, sob o godzinie 16:27 +0530, Rahul Sundaram napisa?(a): [..] > Doing it piecemeal is not going to be worth the effort for you or for > the developers without a consensus. So since you have a long list of > similar things, it would be better to write one solid proposal for all > the changes that you believe needs standardization and send it to the > list so that developers can reach consensus on it and follow those > guidelines. Kindly refer to > http://fedoraproject.org/wiki/Packaging/Guidelines for existing guidelines. This document contains very limited informations about specs coding style. Few poits which are related to subject: - Build root tag but: $ grep BuildRoot: *spec | awk '{print $2}' | sort | uniq -c | wc -l 67 and .. interesting: $ grep BuildRoot: *spec | awk '{print $2}' | sort | grep '%{_tmppath}/%{name}-%{version}-%{release}-root-%\(%{__id_u} -n\)' | wc -l 0 - Parallel make In macros set defined in default set wchich comes with rpm you can find %{__make} macro. So instead adding some non-standard macro IMO better is use standard %{__make}. If someone want perform parallel build they simple can "echo '%__make make -j3' >>~/.rpmmacros". If someon look for next sed regexp it can be something something like "s/make %{?_smp_mflags}/%{__make}/; s/make %{?_smp_flags}/%{__make}/" It is simpler and it is main argument why it will be better use this in this form. - Using %{buildroot} and %{optflags} vs $RPM_BUILD_ROOT and $RPM_OPT_FLAGS This ponit do not clarify which style was choosen by comunity. And this is all. IMO to short and this mani cause of current style chaos (which hides big amout of small non-critical bugs like xorg*). Things like "%{buildroot} vs. $RPM_BUILD_ROOT" are IMO importand because choosing ony one variant as common allow construct simpler indenting tools for spec files. kloczek From sundaram at fedoraproject.org Sat Feb 4 12:07:25 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 04 Feb 2006 17:37:25 +0530 Subject: propozition of specs cleanups In-Reply-To: <1139052496.6900.29.camel@kloczek01.pracownicy.zie> References: <1138959257.25983.84.camel@kloczek01.pracownicy.zie> <43E3302C.2070602@mharris.ca> <1138965417.25983.133.camel@kloczek01.pracownicy.zie> <43E34156.9030402@fedoraproject.org> <1138968719.25983.142.camel@kloczek01.pracownicy.zie> <43E34B61.9000809@fedoraproject.org> <1138985448.25983.182.camel@kloczek01.pracownicy.zie> <43E48898.1040201@fedoraproject.org> <1139052496.6900.29.camel@kloczek01.pracownicy.zie> Message-ID: <43E498FD.5080609@fedoraproject.org> Tomasz K?oczko wrote: >Dnia 04-02-2006, sob o godzinie 16:27 +0530, Rahul Sundaram napisa?(a): >[..] > > >>Doing it piecemeal is not going to be worth the effort for you or for >>the developers without a consensus. So since you have a long list of >>similar things, it would be better to write one solid proposal for all >>the changes that you believe needs standardization and send it to the >>list so that developers can reach consensus on it and follow those >>guidelines. Kindly refer to >>http://fedoraproject.org/wiki/Packaging/Guidelines for existing guidelines. >> >> > >This document contains very limited informations about specs coding >style. > Rpmlint checks for a number of things. redhat-config-config can also be useful. Feel free to propose any number of detailed changes but it might be better to use the wiki to brainstorm and discuss ideas to have them in a central place for easy reference. Refer to http://fedoraproject.org/wiki/WikiEditing for more details. If you need me to add you to the edit group, register your name in the FirstnameLastname format (case sensitive) and let me know the wiki user name. Thanks -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From kloczek at zie.pg.gda.pl Sat Feb 4 12:31:42 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=) Date: Sat, 04 Feb 2006 13:31:42 +0100 Subject: propozition of specs cleanups In-Reply-To: <43E498FD.5080609@fedoraproject.org> References: <1138959257.25983.84.camel@kloczek01.pracownicy.zie> <43E3302C.2070602@mharris.ca> <1138965417.25983.133.camel@kloczek01.pracownicy.zie> <43E34156.9030402@fedoraproject.org> <1138968719.25983.142.camel@kloczek01.pracownicy.zie> <43E34B61.9000809@fedoraproject.org> <1138985448.25983.182.camel@kloczek01.pracownicy.zie> <43E48898.1040201@fedoraproject.org> <1139052496.6900.29.camel@kloczek01.pracownicy.zie> <43E498FD.5080609@fedoraproject.org> Message-ID: <1139056302.6900.44.camel@kloczek01.pracownicy.zie> Dnia 04-02-2006, sob o godzinie 17:37 +0530, Rahul Sundaram napisa?(a): [..] > Rpmlint checks for a number of things. redhat-config-config can also be > useful. Feel free to propose any number of detailed changes but it might > be better to use the wiki to brainstorm and discuss ideas to have them > in a central place for easy reference. Refer to > http://fedoraproject.org/wiki/WikiEditing for more details. If you need > me to add you to the edit group, register your name in the > FirstnameLastname format (case sensitive) and let me know the wiki user > name. Let me allow wait for look on how effectively/fast will be solved things wchich I list in this thread before next step :) I'm not interested to be involved in kind biurocracy. Each document have own style and my englis (as you see) isn't perfect (I know my limitations). On technical level bugs are allways bugs and if they are some responsible people must do someting for fixing this. I'm show where some class bugs sits and even how few can be fixed (using simple sed regexp) and from this point this is more than only bug raport .. this is full bugfix. Again: let me allow look is fixing this will take few seconds, minutes or few days, weeks or more. regardads kloczek From sundaram at fedoraproject.org Sat Feb 4 12:47:19 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 04 Feb 2006 18:17:19 +0530 Subject: propozition of specs cleanups In-Reply-To: <1139056302.6900.44.camel@kloczek01.pracownicy.zie> References: <1138959257.25983.84.camel@kloczek01.pracownicy.zie> <43E3302C.2070602@mharris.ca> <1138965417.25983.133.camel@kloczek01.pracownicy.zie> <43E34156.9030402@fedoraproject.org> <1138968719.25983.142.camel@kloczek01.pracownicy.zie> <43E34B61.9000809@fedoraproject.org> <1138985448.25983.182.camel@kloczek01.pracownicy.zie> <43E48898.1040201@fedoraproject.org> <1139052496.6900.29.camel@kloczek01.pracownicy.zie> <43E498FD.5080609@fedoraproject.org> <1139056302.6900.44.camel@kloczek01.pracownicy.zie> Message-ID: <43E4A257.6080801@fedoraproject.org> Tomasz K?oczko wrote: >Dnia 04-02-2006, sob o godzinie 17:37 +0530, Rahul Sundaram napisa?(a): >[..] > > >>Rpmlint checks for a number of things. redhat-config-config can also be >>useful. Feel free to propose any number of detailed changes but it might >>be better to use the wiki to brainstorm and discuss ideas to have them >>in a central place for easy reference. Refer to >>http://fedoraproject.org/wiki/WikiEditing for more details. If you need >>me to add you to the edit group, register your name in the >>FirstnameLastname format (case sensitive) and let me know the wiki user >>name. >> >> > >Let me allow wait for look on how effectively/fast will be solved things >wchich I list in this thread before next step :) > > It might very well just get lost in the list noise. Not all the relevant developers are reading every mail in this list either. >I'm not interested to be involved in kind biurocracy. Each document have >own style and my englis (as you see) isn't perfect (I know my >limitations). > Havent heard anyone refer to using the wiki as being bureaucratic before. The level of English wouldnt be a big issue as long as you can list your proposed changes in a clear central reference point it would be easier to tackle. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From mharris at mharris.ca Sat Feb 4 12:58:54 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Sat, 04 Feb 2006 07:58:54 -0500 Subject: Request for testers: Video hardware autodetection Message-ID: <43E4A50E.5070209@mharris.ca> The latest xorg-x11-drv-* driver packages contain videoaliases files for kudzu et al. to use for video card autodetection and driver mapping. The current PCI ID -> driver mappings were derived by converting the old pcitable/Cards databases into a new database named "videoaliases", and then subsequently dividing that into per driver files, and including them in each driver package. To that, I've added missing PCI IDs which were reported in bugzilla and spotted in mailing lists, etc., however the data is not 100% accurate and up to date with the current driver support. In the longterm, the goal is to have these metadata files be completely unnecessary, and have the X server know what to do without any configuration. In the mid-term, the goal is to have the metadata files automatically generated at rpm package build time, by a utility that can pull the data right out of the drivers, however that's not easily doable with the current ugly inconsistent state of the driver code. So, for the shortterm, I'd like everyone to make a backup copy of your xorg.conf, and to test the latest drivers with "system-config-display --reconfig" to ensure that your video hardware is autodetected properly. If you have a video card which is assigned the "vesa" driver from the above test, then it is either not supported by the drivers, or we're missing a PCI ID to driver mapping for that card/chip. To determine if it is supported by the driver, hand edit the xorg.conf and replace the vesa driver with the native X driver for the particular vendor. ie: "nv" for Nvidia, "ati" for ATI, etc., and test to see if X starts up. If the X server starts up ok with the native X driver, and it did not get autodetected properly by system-config-display, and you've confirmed you are using the absolute latest rawhide video driver packages, then please file a bug report in bugzilla against the proper xorg-x11-drv-? package for your driver, and include the X server log and config file as individual uncompressed file attachments. Once I've got these confirmations, I'll update the driver packages to reflect any additions needed. Thanks in advance. P.S. If anyone out there wants to go on a mission, and manually inspect the source code of every driver, and try to determine the PCI IDs supported by every one, please feel free to give it a shot, however I must warn you that it is not very fun, and quite tedious. ;o) -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From sundaram at fedoraproject.org Sat Feb 4 13:31:10 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 04 Feb 2006 19:01:10 +0530 Subject: Proposed and major updates policy Message-ID: <43E4AC9E.2050907@fedoraproject.org> Hi Currently the usage of updates-testing repository for proposed updates to a release is entirely based on the package maintainer and in many cases seems to be arbitrary for the end users. Can we have a policy to ensure to that all the updates have a week or so of testing period in the updates-testing repository with the exception of security updates which go through a shorter duration of testing?. It might also be better to have some consistency in between providing updates for major revisions of packages. KDE got a major update while GNOME and Firefox didnt in Fedora Core 4 as an example of current status. While the current amount of feedback that we receive from end users on the packages in updates-testing repository is low to non existent, it would be better to encourage usage of that and provide interested testers a chance to send in feedback rather than releasing it immediately to the updates repository leading to potential regressions more rapidly. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From jfrieben at freesurf.fr Sat Feb 4 12:51:39 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Sat, 4 Feb 2006 13:51:39 +0100 (CET) Subject: Xorg 6.9 Update for FC4? In-Reply-To: <1139023771.3267.8.camel@tuxhugger> References: <1139023771.3267.8.camel@tuxhugger> Message-ID: <57896.89.50.36.176.1139057499.squirrel@arlette.freesurf.fr> A couple of persons have built Xorg 6.9 RPMs for FC4 based upon M. Harris' test packages for Xorg 6.8.99.14. Check the "fedora-devel" and/or the "Xorg" mailing lists. Xorg 6.9 works nicely on FC4. I definitely recommend the upgrade for suitable hardware. For my Savage based IBM ThinkPad T23, this was the only way to obtain 3D acceleration. For my ATI 7200 (R100) equipped desktop PC however, even current rawhide (modular Xorg 7.0.0) has not been able to resolve the long standing X lock issues when DRI is enabled! > Hi all. > > With the recent release of the modular X.org X11R7, will Fedora Core 4 > receive an update to its monolithic counterpart X11R6.9? > From fedora at adslpipe.co.uk Sat Feb 4 14:00:44 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Sat, 04 Feb 2006 14:00:44 +0000 Subject: Request for testers: Video hardware autodetection In-Reply-To: <43E4A50E.5070209@mharris.ca> References: <43E4A50E.5070209@mharris.ca> Message-ID: <43E4B38C.9030400@adslpipe.co.uk> Mike A. Harris wrote: > If you have a video card which is assigned the "vesa" driver > from the above test, then it is either not supported by the > drivers, or we're missing a PCI ID to driver mapping for that > card/chip. I have a Sapphire ATI X550 card, it has never been properly detected by xorg, it picks vesa driver, but qll works great if I add a "ChipId 0x5b62" and set the driver to radeon in the device section. I did tag this onto a fd.o/xorg bugzilla that was requesting missing radeon PCIDs around the X11R7RC timeframe https://bugs.freedesktop.org/show_bug.cgi?id=4284#c3 Would be nice if it gets added Just a very quick by the by .... I'm not expecting h/w openGL (without the fglrx drivers) but with ati/radeon drivers should I be getting Mesa as a software fallback, as I'm not ... snippet from lspci 01:00.0 VGA compatible controller: ATI Technologies Inc RV370 [ATI Sapphire X550 Silent] 01:00.1 Display controller: ATI Technologies Inc RV370 secondary [ATI Sapphire X550 Silent] snippet from lspci -nvv 01:00.0 0300: 1002:5b63 Subsystem: 174b:1490 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- References: <43E4A50E.5070209@mharris.ca> <43E4B38C.9030400@adslpipe.co.uk> Message-ID: <43E4B631.6000502@adslpipe.co.uk> Andy Burns wrote: > I have a Sapphire ATI X550 card Just waiting for today's rawhide to rsync, if still exists after that (I didn't *notice* any drv-ati update) I'll BZ it ... From fedora at adslpipe.co.uk Sat Feb 4 14:22:32 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Sat, 04 Feb 2006 14:22:32 +0000 Subject: Request for testers: Video hardware autodetection In-Reply-To: <43E4B631.6000502@adslpipe.co.uk> References: <43E4A50E.5070209@mharris.ca> <43E4B38C.9030400@adslpipe.co.uk> <43E4B631.6000502@adslpipe.co.uk> Message-ID: <43E4B8A8.3000909@adslpipe.co.uk> Andy Burns wrote: > I didn't *notice* any drv-ati update You deliberately confused me by using that *alphnumeric* sorting again didn't you :-P Can't you use the same randomising hash function my brain does? I wish I could find the spec for that function btw ... From mike at miketc.com Sat Feb 4 14:29:45 2006 From: mike at miketc.com (Mike Chambers) Date: Sat, 04 Feb 2006 08:29:45 -0600 Subject: Request for testers: Video hardware autodetection In-Reply-To: <43E4A50E.5070209@mharris.ca> References: <43E4A50E.5070209@mharris.ca> Message-ID: <1139063385.2813.1.camel@scrappy.miketc.com> On Sat, 2006-02-04 at 07:58 -0500, Mike A. Harris wrote: > If you have a video card which is assigned the "vesa" driver > from the above test, then it is either not supported by the > drivers, or we're missing a PCI ID to driver mapping for that > card/chip. To determine if it is supported by the driver, > hand edit the xorg.conf and replace the vesa driver with the > native X driver for the particular vendor. ie: "nv" for > Nvidia, "ati" for ATI, etc., and test to see if X starts up. > > If the X server starts up ok with the native X driver, and it > did not get autodetected properly by system-config-display, > and you've confirmed you are using the absolute latest rawhide > video driver packages, then please file a bug report in > bugzilla against the proper xorg-x11-drv-? package for your > driver, and include the X server log and config file as > individual uncompressed file attachments. Radeon 9000 Pro detected as vesa driver. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180001 -- Mike Chambers Madisonville, KY "It's only funny until someone gets hurt...Then it's hilarious!" From mharris at mharris.ca Sat Feb 4 14:32:52 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Sat, 04 Feb 2006 09:32:52 -0500 Subject: Request for testers: Video hardware autodetection In-Reply-To: <43E4A50E.5070209@mharris.ca> References: <43E4A50E.5070209@mharris.ca> Message-ID: <43E4BB14.3040609@mharris.ca> Mike A. Harris wrote: > The latest xorg-x11-drv-* driver packages contain videoaliases > files for kudzu et al. to use for video card autodetection and > driver mapping. One further clarification I should make, is that this request was for "video card" detection. Monitor/display detection is a separate issue, which is done by the ddcprobe utility, which gets invoked by system-config-display, and is x86 only. The X server can also do monitor detection, however our default configurations specify the monitor in the config file in most cases. The X server still probes the display when it is possible to do so, but that information is not always used. Video driver DDC problems, generally should be reported directly to X.Org bugzilla to ensure the maintainers of the particular driver see the issue. In some cases it is a driver bug, in other cases a hardware limitation, or a software limitation that can't easily be overcome. KVM switches can also block the DDC signal. Another problem which someone has brought up, is that on DFP and LCD displays, and in particular wide-screen panels, often the resolution that gets configured by default, does not match the physical resolution of the DFP/LCD panel, causing hardware scaling to be used, resulting in an ugly display. For laptops and systems with Intel hardware, this is a video BIOS limitation which can not be worked around currently without documentation from Intel. I believe that some "via" video hardware has a similar problem. In all cases of this nature, my recommendation is to try and narrow down the problem you're having /before/ reporting a bug anywhere. A good place to get helpful troubleshooting info, is xorg at lists.freedesktop.org and #xorg IRC channel on freenode. In some cases, these limitations can be worked around with ugly hacks that are out there (ie: i810resolution hack), and in other cases modelines need to be added to the xorg.conf. Of course there may be a real bug somewhere, but it'll be more evident once you've done some direct investigation based off advice from the xorg mailing list. Only then should one report a bug, and it should be filed in the X.Org bugzilla at: http://bugs.freedesktop.org Hope this helps. I'm getting good feedback from people, so I'll try and post more advice here if more examples pop up. If someone feels like summarizing any of this on the Fedora wiki, or paraphrasing, etc., feel free. Thanks everyone for testing, and providing bug reports and other forms of feedback! -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From pgraner at redhat.com Sat Feb 4 14:35:29 2006 From: pgraner at redhat.com (Pete Graner) Date: Sat, 04 Feb 2006 09:35:29 -0500 Subject: Request for testers: Video hardware autodetection In-Reply-To: <43E4A50E.5070209@mharris.ca> References: <43E4A50E.5070209@mharris.ca> Message-ID: <43E4BBB1.7020703@redhat.com> Mike, Seems to have broke multi-head configs. I can't get it to work with the radeon or ati drivers. lspci show me having (which I do) ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] My left head works great however the right one all you can see the background image but the panels (top and bottom) and skewed with lines running thru them. I've tried getting screen shots but all I get is a solid black image off of any tool I try. Again the left head looks good the right is a black square. I guess I could take a pic with a digital camera if it would help. Not sure what component the would go under I'm assuming the radeon driver... BTW on i386, intel Pent 4 2.4ghz Pete Mike A. Harris wrote: > The latest xorg-x11-drv-* driver packages contain videoaliases > files for kudzu et al. to use for video card autodetection and > driver mapping. > > The current PCI ID -> driver mappings were derived by converting > the old pcitable/Cards databases into a new database named > "videoaliases", and then subsequently dividing that into per > driver files, and including them in each driver package. > > To that, I've added missing PCI IDs which were reported in bugzilla > and spotted in mailing lists, etc., however the data is not 100% > accurate and up to date with the current driver support. > > In the longterm, the goal is to have these metadata files be > completely unnecessary, and have the X server know what to do > without any configuration. In the mid-term, the goal is to > have the metadata files automatically generated at rpm package > build time, by a utility that can pull the data right out of > the drivers, however that's not easily doable with the current > ugly inconsistent state of the driver code. > > So, for the shortterm, I'd like everyone to make a backup copy > of your xorg.conf, and to test the latest drivers with > "system-config-display --reconfig" to ensure that your video > hardware is autodetected properly. > > If you have a video card which is assigned the "vesa" driver > from the above test, then it is either not supported by the > drivers, or we're missing a PCI ID to driver mapping for that > card/chip. To determine if it is supported by the driver, > hand edit the xorg.conf and replace the vesa driver with the > native X driver for the particular vendor. ie: "nv" for > Nvidia, "ati" for ATI, etc., and test to see if X starts up. > > If the X server starts up ok with the native X driver, and it > did not get autodetected properly by system-config-display, > and you've confirmed you are using the absolute latest rawhide > video driver packages, then please file a bug report in > bugzilla against the proper xorg-x11-drv-? package for your > driver, and include the X server log and config file as > individual uncompressed file attachments. > > Once I've got these confirmations, I'll update the driver > packages to reflect any additions needed. > > Thanks in advance. > > > > P.S. If anyone out there wants to go on a mission, and manually > inspect the source code of every driver, and try to determine > the PCI IDs supported by every one, please feel free to give > it a shot, however I must warn you that it is not very fun, > and quite tedious. ;o) > > -- Pete Graner email: From mharris at mharris.ca Sat Feb 4 16:24:05 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Sat, 04 Feb 2006 11:24:05 -0500 Subject: Request for testers: Video hardware autodetection In-Reply-To: <43E4BBB1.7020703@redhat.com> References: <43E4A50E.5070209@mharris.ca> <43E4BBB1.7020703@redhat.com> Message-ID: <43E4D525.6020608@mharris.ca> Pete Graner wrote: > Mike, > > Seems to have broke multi-head configs. I can't get it to work with the > radeon or ati drivers. lspci show me having (which I do) ATI > Technologies Inc Radeon RV100 QY [Radeon 7000/VE] > > My left head works great however the right one all you can see the > background image but the panels (top and bottom) and skewed with lines > running thru them. I've tried getting screen shots but all I get is a > solid black image off of any tool I try. Again the left head looks good > the right is a black square. I guess I could take a pic with a digital > camera if it would help. > > Not sure what component the would go under I'm assuming the radeon > driver... > > BTW on i386, intel Pent 4 2.4ghz Can you file that in Xorg bugzilla, and CC me on it? Radeon 7000 support seems to be deteriorating since FC3. ;/ TIA -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From gilboad at gmail.com Sat Feb 4 16:27:37 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sat, 04 Feb 2006 18:27:37 +0200 Subject: Proposed and major updates policy In-Reply-To: <43E4AC9E.2050907@fedoraproject.org> References: <43E4AC9E.2050907@fedoraproject.org> Message-ID: <1139070457.7617.13.camel@gilboa-home-dev.localhost> On Sat, 2006-02-04 at 19:01 +0530, Rahul Sundaram wrote: > Hi > > Currently the usage of updates-testing repository for proposed updates > to a release is entirely based on the package maintainer and in many > cases seems to be arbitrary for the end users. Can we have a policy to > ensure to that all the updates have a week or so of testing period in > the updates-testing repository with the exception of security updates > which go through a shorter duration of testing?. It might also be better > to have some consistency in between providing updates for major > revisions of packages. KDE got a major update while GNOME and Firefox > didnt in Fedora Core 4 as an example of current status. > > While the current amount of feedback that we receive from end users on > the packages in updates-testing repository is low to non existent, it > would be better to encourage usage of that and provide interested > testers a chance to send in feedback rather than releasing it > immediately to the updates repository leading to potential regressions > more rapidly. > I second that. The lack of FC package update policy is a real pain in the back side. The KDE 3.5.x release backlash was just an example of why such a policy must be set. Might I further suggest that a message will be sent to fedora-testing/fedora-users once a package enters update-testing? At least in my case, when I see such a message in fedora-testers (usually kernel/udev/openoffice) I do my best to test it and report back. I assume that posting this info in fedora-users will encourage others to do the same. Gilboa From benjy.grogan at gmail.com Sat Feb 4 16:51:12 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Sat, 4 Feb 2006 11:51:12 -0500 Subject: XGL In-Reply-To: <43E15BEF.3070405@mharris.ca> References: <43E15BEF.3070405@mharris.ca> Message-ID: Alright. Thanks for the info. I'm looking forward to some of these future X technologies. Is there a good source of information somewhere about the architecture of X11 R7.0? As well as some of these technologies being developed by RedHat and Sun? At the moment I'm only aware of Novell's work on X. It's going to be interesting to see how Fedora and other distributions turn out in the next few years. Best of luck to you guys. Benji On 2/1/06, Mike A. Harris wrote: > > Benjy Grogan wrote: > > I hear that in a week or so Novell will be releasing the source code to > > XGL for X11 7.0. Will it be possible to have XGL available in Extras > > for FC5? I'm guessing it's one of those new X11 modules that v7.0 is > > all about. But I know little about XGL and would like to test it out to > > know more. It's going to be in NLD 10 in a few months. > > There are a lot of X related "goodies" that are up and coming in the > X development world, including technologies being developed by Red Hat, > Novell, Sun, and various others in the community. The current plan for > Fedora Core 5, is to ship X11R7.0 as the official X implementation, > including the Xorg X server. > > The various developmental/experimental technologies being developed > by the above parties will most likely be available to Fedora users in > one form or another over time, however everything is quite experimental > at the current point in time to make any solid speculation for the > inclusion of other components into Fedora Core 5 at this time. > > Either way, anything not included in Core, will very likely either > end up in Fedora Extras, or rpm packaged in some other experimental > repository, making it available for Fedora users to play with. > > Keep in mind, both end users and developers alike are equally > anticipating the various new eye-candy technologies, and the X.Org > community is pretty close knit. As such, you can expect that > there'll be lots of fun stuff to play with in the not distant > future. ;o) > > As various bits and pieces become less experimental, and more ready > for people to play with, myself or someone else will likely post more > information on this list and/or on the developmental X.Org and/or > Fedora IRC channels. > > For now though, patience is a virtue. ;o) > > HTH > > > -- > Mike A. Harris * Open Source Advocate * http://mharris.ca > Proud Canadian. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vonbrand at inf.utfsm.cl Sat Feb 4 17:34:53 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Sat, 04 Feb 2006 14:34:53 -0300 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: Message from Jeremy Katz of "Fri, 03 Feb 2006 17:39:47 CDT." <1139006387.2652.29.camel@bree.local.net> Message-ID: <200602041734.k14HYr2C006710@laptop11.inf.utfsm.cl> Jeremy Katz wrote: > Although I hate to do it, it looks like we're going to have to slip > Fedora Core 5 test3 by a week. There is an ABI change in the gcc/glibc > stack that requires a rebuild of the entire distribution. May I ask what the change is, and how it affects stuff? ABI changes in C are scary... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From rhally at mindspring.com Sat Feb 4 17:49:56 2006 From: rhally at mindspring.com (Richard Hally) Date: Sat, 04 Feb 2006 12:49:56 -0500 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <200602041734.k14HYr2C006710@laptop11.inf.utfsm.cl> References: <200602041734.k14HYr2C006710@laptop11.inf.utfsm.cl> Message-ID: <43E4E944.5070609@mindspring.com> Horst von Brand wrote: > Jeremy Katz wrote: >> Although I hate to do it, it looks like we're going to have to slip >> Fedora Core 5 test3 by a week. There is an ABI change in the gcc/glibc >> stack that requires a rebuild of the entire distribution. > > May I ask what the change is, and how it affects stuff? ABI changes in C > are scary... from a previous email: > We are changing long double type on ppc{32,64}, s390{,x}, sparc (32-bit), > and alpha. Previously long double has been the same type as double > on these architectures, now it will be either IEEE 754 quad format > long double (112 (+1 implicit) bits mantissa, 15 bits exponent, 1 bit sign; > on s390{,x}, sparc and alpha) or IBM extended format (pair of double values > with some special rules). > glibc has been changed so that it is backwards compatible with programs > and shared libraries that use 64-bit long double, but also supports the > 128-bit one, even when compiling packages you can choose the long double > format (-mlong-double-64 resp. -mlong-double-128, which will be the > new default). libstdc++.so.6 is also made backwards compatible with > 64-bit long double, but supporting 128-bit long double as well (and > similarly libgcc_s.so.1). > > In addition to this, there are other reasons why a complete rebuild of the > entire distribution is desirable: > 1) there used to be a bug on i?86 which caused incorrect .eh_frame section > being generated (terminated before end of section), which makes e.g. > valgrind complain loudly and also means .eh_frame_hdr can't be used to speed > up exception handling. This bug has been fixed a long time ago, but many > packages haven't been rebuilt since then. > 2) on ia64 debug info wasn't properly describing function prologues > 3) many binaries on ia64 were having text relocations, which is bad > from security POV > 4) on i?86 and x86_64, -mtune=generic option has been added, which means > tuning for a pool of most commonly used CPUs. According to SPEC results > the code is no worse than -mtune={nocona,pentium4} used before on Intel > CPUs and is significantly better on AMD CPUs. > > Jakub From jkeating at redhat.com Sat Feb 4 18:22:47 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 04 Feb 2006 10:22:47 -0800 Subject: Java bug status In-Reply-To: <1139051613.2795.4.camel@xpc.home.erwinrol.com> References: <1139051613.2795.4.camel@xpc.home.erwinrol.com> Message-ID: <1139077367.3188.10.camel@yoda.loki.me> On Sat, 2006-02-04 at 12:13 +0100, Erwin Rol wrote: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179228 > > The priority of this bug is just "normal" but since it breaks a lot of > software (and if it is a kernel issue, it breaks maybe even more than > just the java software) shouldn't its priority be "high" ? Unfortunately priority and severity gets abused by bug reporters and is largely ignored by the assignees. I have added this bug as a blocker to FC5 so that we can keep track of it for release time. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From arjan at fenrus.demon.nl Sat Feb 4 19:47:19 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sat, 04 Feb 2006 20:47:19 +0100 Subject: flash-plugin missing text on preferences In-Reply-To: <43E34CA1.4090500@email.it> References: <43E34CA1.4090500@email.it> Message-ID: <1139082442.3131.4.camel@laptopd505.fenrus.org> On Fri, 2006-02-03 at 13:29 +0100, Andrea wrote: > if I try to modify preference of flash-plugin on firefox I can't see text? > > to use it I modify in selinux "Allow executables to run with executable > stack" I'm sure you're aware that with the "execstack" program, you can just turn the flash plugin into "don't need executable stack", making it both more secure, and not needing this selinux hack, right? (if not.. you are now ;) From lamont at gurulabs.com Sat Feb 4 19:55:19 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Sat, 4 Feb 2006 12:55:19 -0700 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <43E48DDD.4060508@vip.hr> References: <1139006387.2652.29.camel@bree.local.net> <1139014200.2863.65.camel@yoda.loki.me> <43E48DDD.4060508@vip.hr> Message-ID: <200602041255.23869.lamont@gurulabs.com> On Saturday 04 February 2006 04:19am, Igor Jagec wrote: > Jesse Keating wrote: [snip] Enough with the birthdays already. :) How about if we slip FC5 just a little more so that it is released in May on FC4's 1st anniversary? That would give us enough time to make a test4 and maybe even a test5 release to iron out all the new X bugs. hehe, just kidding. > > during that time to make sure FC5 is a great release for YOUR birthday > > (; > > It's gonna be a great release. It's been a long time since FC4 was > released... I suppose that RHEL5 will be based on FC5 since it took as > much time to build it. Maybe it is a good idea to make release cycle to > one year instead of 4 to 6 months as it is said it's going to be for > Fedora Core. After 2-1/2 years, I think Fedora development has all but proved that 6 months is the minimum time between good distribution releases. It doesn't look like we're ever going to see 4 months. I'm not saying that 4 months isn't possible, just that the track record seems to show that 6 months is the "right" timeframe. I'm not saying that 4 months is a bad goal. On the contrary, I think setting tough goals is (usually) a good thing; it spurs us all on to accomplish things we never have before. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jdieter99 at gmx.net Sat Feb 4 20:04:09 2006 From: jdieter99 at gmx.net (Jonathan Dieter) Date: Sat, 04 Feb 2006 22:04:09 +0200 Subject: Xorg 6.9 Update for FC4? In-Reply-To: <20060204140103.BFF75730B0@hormel.redhat.com> References: <20060204140103.BFF75730B0@hormel.redhat.com> Message-ID: <43E508B9.80702@gmx.net> Mike, if it helps, I'd love to be able to play with Xorg 6.9 on my FC4 box, and I would be very appreciative of any time you wanted to spend on creating some experimental rpms. Jonathan From lamont at gurulabs.com Sat Feb 4 20:04:14 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Sat, 4 Feb 2006 13:04:14 -0700 Subject: Proposed and major updates policy In-Reply-To: <1139070457.7617.13.camel@gilboa-home-dev.localhost> References: <43E4AC9E.2050907@fedoraproject.org> <1139070457.7617.13.camel@gilboa-home-dev.localhost> Message-ID: <200602041304.19683.lamont@gurulabs.com> On Saturday 04 February 2006 09:27am, Gilboa Davara wrote: > On Sat, 2006-02-04 at 19:01 +0530, Rahul Sundaram wrote: > > Hi [snip] > I second that. > The lack of FC package update policy is a real pain in the back side. > The KDE 3.5.x release backlash was just an example of why such a policy > must be set. > > Might I further suggest that a message will be sent to > fedora-testing/fedora-users once a package enters update-testing? > At least in my case, when I see such a message in fedora-testers > (usually kernel/udev/openoffice) I do my best to test it and report > back. I assume that posting this info in fedora-users will encourage > others to do the same. Third. Also, I would suggest a new mailing list, fedora-testing-announce, be created. Some of us do not follow Fedora Testing or Fedora Users lists because there's just too much traffic. I have a hard enough time keeping up with the Fedora Developer list in addition to the other lists. Having such testing package availability announcements would make it much easier for me to pick up testing packages and try them out. Thanks to all package maintainers for all the hard work on updating packages. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mharris at mharris.ca Sat Feb 4 20:06:54 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Sat, 04 Feb 2006 15:06:54 -0500 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <200602041255.23869.lamont@gurulabs.com> References: <1139006387.2652.29.camel@bree.local.net> <1139014200.2863.65.camel@yoda.loki.me> <43E48DDD.4060508@vip.hr> <200602041255.23869.lamont@gurulabs.com> Message-ID: <43E5095E.3060804@mharris.ca> Lamont R. Peterson wrote: > On Saturday 04 February 2006 04:19am, Igor Jagec wrote: > >>Jesse Keating wrote: > > [snip] > > Enough with the birthdays already. :) > > How about if we slip FC5 just a little more so that it is released in May on > FC4's 1st anniversary? That would give us enough time to make a test4 and > maybe even a test5 release to iron out all the new X bugs. > > hehe, just kidding. That's not too bad of an idea, however if we do that, X11R7.1 is scheduled for May, so we should wait until April. ;) On a serious note though, before anyone asks.... Since 7.1 is going to be out very soon after FC5, there is a very strong likelyhood that we'll update FC5 to X11R7.1 sometime after it is released. And since it is all modular, that might happen to individual pieces over time instead of one big plop. Ah, the glory of modular X. ;) >>>during that time to make sure FC5 is a great release for YOUR birthday >>>(; >> >>It's gonna be a great release. It's been a long time since FC4 was >>released... I suppose that RHEL5 will be based on FC5 since it took as >>much time to build it. Maybe it is a good idea to make release cycle to >>one year instead of 4 to 6 months as it is said it's going to be for >>Fedora Core. I think our 6 month cycle plan remains, but will likely vary depending on various factors. I'd like to see it be a 9 month cycle that can vary earlier or later though, but that's just my personal opinion. I dunno who else would agree with me on that. ;) > After 2-1/2 years, I think Fedora development has all but proved that 6 months > is the minimum time between good distribution releases. It doesn't look like > we're ever going to see 4 months. I'd definitely agree with that. 4 months would give time to update packages, file off some rough edges, do almost no development, and release. That's no good. ;) > I'm not saying that 4 months isn't possible, just that the track record seems > to show that 6 months is the "right" timeframe. I'd say "minimum" timeframe. ;) > I'm not saying that 4 months is a bad goal. On the contrary, I think setting > tough goals is (usually) a good thing; it spurs us all on to accomplish > things we never have before. A 4 month release would give me a heart attack I think. :) -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Sat Feb 4 20:11:29 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Sat, 04 Feb 2006 15:11:29 -0500 Subject: Proposed and major updates policy In-Reply-To: <200602041304.19683.lamont@gurulabs.com> References: <43E4AC9E.2050907@fedoraproject.org> <1139070457.7617.13.camel@gilboa-home-dev.localhost> <200602041304.19683.lamont@gurulabs.com> Message-ID: <43E50A71.9060905@mharris.ca> Lamont R. Peterson wrote: > On Saturday 04 February 2006 09:27am, Gilboa Davara wrote: > >>On Sat, 2006-02-04 at 19:01 +0530, Rahul Sundaram wrote: >> >>>Hi > > [snip] > >>I second that. >>The lack of FC package update policy is a real pain in the back side. >>The KDE 3.5.x release backlash was just an example of why such a policy >>must be set. >> >>Might I further suggest that a message will be sent to >>fedora-testing/fedora-users once a package enters update-testing? >>At least in my case, when I see such a message in fedora-testers >>(usually kernel/udev/openoffice) I do my best to test it and report >>back. I assume that posting this info in fedora-users will encourage >>others to do the same. > > > Third. > > Also, I would suggest a new mailing list, fedora-testing-announce, be created. > Some of us do not follow Fedora Testing or Fedora Users lists because there's > just too much traffic. I have a hard enough time keeping up with the Fedora > Developer list in addition to the other lists. Having such testing package > availability announcements would make it much easier for me to pick up > testing packages and try them out. > > Thanks to all package maintainers for all the hard work on updating packages. IMHO, testing announce messages should just go directly to fedora-test-list. That way it is guaranteed all "testers" get the email. My definition of a tester being someone who is subscribed to the fedora-test-list of course. ;) I don't have the stats, but I would guess that if they were separate lists, less people would be on the announce list than on the test list, and there's already a deficit of people using updates-testing. To increase that, announcements should hit as many people as possible. Perhaps posting them to redhat-list, and fedora-list too. ;) Ok, maybe that's too much.. :) -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From lamont at gurulabs.com Sat Feb 4 20:15:23 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Sat, 4 Feb 2006 13:15:23 -0700 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <43E5095E.3060804@mharris.ca> References: <1139006387.2652.29.camel@bree.local.net> <200602041255.23869.lamont@gurulabs.com> <43E5095E.3060804@mharris.ca> Message-ID: <200602041315.27763.lamont@gurulabs.com> On Saturday 04 February 2006 01:06pm, Mike A. Harris wrote: > Lamont R. Peterson wrote: > > On Saturday 04 February 2006 04:19am, Igor Jagec wrote: > >>Jesse Keating wrote: > > > > [snip] > > > > Enough with the birthdays already. :) > > > > How about if we slip FC5 just a little more so that it is released in May > > on FC4's 1st anniversary? That would give us enough time to make a test4 > > and maybe even a test5 release to iron out all the new X bugs. > > > > hehe, just kidding. > > That's not too bad of an idea, however if we do that, X11R7.1 is > scheduled for May, so we should wait until April. ;) > > On a serious note though, before anyone asks.... Since 7.1 is going > to be out very soon after FC5, there is a very strong likelyhood that > we'll update FC5 to X11R7.1 sometime after it is released. And since > it is all modular, that might happen to individual pieces over time > instead of one big plop. > > Ah, the glory of modular X. ;) Cool. > >>>during that time to make sure FC5 is a great release for YOUR birthday > >>>(; > >> > >>It's gonna be a great release. It's been a long time since FC4 was > >>released... I suppose that RHEL5 will be based on FC5 since it took as > >>much time to build it. Maybe it is a good idea to make release cycle to > >>one year instead of 4 to 6 months as it is said it's going to be for > >>Fedora Core. > > I think our 6 month cycle plan remains, but will likely vary depending > on various factors. I'd like to see it be a 9 month cycle that can > vary earlier or later though, but that's just my personal opinion. I > dunno who else would agree with me on that. ;) Now that you mention it, I like it. I would support the idea. > > After 2-1/2 years, I think Fedora development has all but proved that 6 > > months is the minimum time between good distribution releases. It > > doesn't look like we're ever going to see 4 months. > > I'd definitely agree with that. 4 months would give time to update > packages, file off some rough edges, do almost no development, and > release. That's no good. ;) > > > I'm not saying that 4 months isn't possible, just that the track record > > seems to show that 6 months is the "right" timeframe. > > I'd say "minimum" timeframe. ;) You are correct; much better. > > I'm not saying that 4 months is a bad goal. On the contrary, I think > > setting tough goals is (usually) a good thing; it spurs us all on to > > accomplish things we never have before. > > A 4 month release would give me a heart attack I think. :) LOL. OK, in that case, should we (not meaning me, as I have to real "say" in anything here) change the "official" copy that says 4-6 months release cycle? -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lamont at gurulabs.com Sat Feb 4 20:18:54 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Sat, 4 Feb 2006 13:18:54 -0700 Subject: Proposed and major updates policy In-Reply-To: <43E50A71.9060905@mharris.ca> References: <43E4AC9E.2050907@fedoraproject.org> <200602041304.19683.lamont@gurulabs.com> <43E50A71.9060905@mharris.ca> Message-ID: <200602041319.03294.lamont@gurulabs.com> On Saturday 04 February 2006 01:11pm, Mike A. Harris wrote: > Lamont R. Peterson wrote: > > On Saturday 04 February 2006 09:27am, Gilboa Davara wrote: > >>On Sat, 2006-02-04 at 19:01 +0530, Rahul Sundaram wrote: > >>>Hi > > > > [snip] > > > >>I second that. > >>The lack of FC package update policy is a real pain in the back side. > >>The KDE 3.5.x release backlash was just an example of why such a policy > >>must be set. > >> > >>Might I further suggest that a message will be sent to > >>fedora-testing/fedora-users once a package enters update-testing? > >>At least in my case, when I see such a message in fedora-testers > >>(usually kernel/udev/openoffice) I do my best to test it and report > >>back. I assume that posting this info in fedora-users will encourage > >>others to do the same. > > > > Third. > > > > Also, I would suggest a new mailing list, fedora-testing-announce, be > > created. Some of us do not follow Fedora Testing or Fedora Users lists > > because there's just too much traffic. I have a hard enough time keeping > > up with the Fedora Developer list in addition to the other lists. Having > > such testing package availability announcements would make it much easier > > for me to pick up testing packages and try them out. > > > > Thanks to all package maintainers for all the hard work on updating > > packages. > > IMHO, testing announce messages should just go directly to > fedora-test-list. That way it is guaranteed all "testers" > get the email. My definition of a tester being someone who > is subscribed to the fedora-test-list of course. ;) OK. I can see that. > I don't have the stats, but I would guess that if they were > separate lists, less people would be on the announce list than > on the test list, and there's already a deficit of people using > updates-testing. To increase that, announcements should hit > as many people as possible. Perhaps posting them to redhat-list, > and fedora-list too. ;) Ok, maybe that's too much.. :) Well, the reason I'm not subscribed to fedora-test-list is that there is way too much going on there leading up to test1 and going through until release for each release. If fedora-updates-testing-list & fedora-test-list (for testX releases) were separate, that might help get more people on boeard for update testing. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pgraner at redhat.com Sat Feb 4 20:48:27 2006 From: pgraner at redhat.com (Pete Graner) Date: Sat, 04 Feb 2006 15:48:27 -0500 Subject: Request for testers: Video hardware autodetection In-Reply-To: <43E4D525.6020608@mharris.ca> References: <43E4A50E.5070209@mharris.ca> <43E4BBB1.7020703@redhat.com> <43E4D525.6020608@mharris.ca> Message-ID: <43E5131B.5030401@redhat.com> Mike A. Harris wrote: > Pete Graner wrote: >> Mike, >> >> Seems to have broke multi-head configs. I can't get it to work with >> the radeon or ati drivers. lspci show me having (which I do) ATI >> Technologies Inc Radeon RV100 QY [Radeon 7000/VE] >> >> My left head works great however the right one all you can see the >> background image but the panels (top and bottom) and skewed with lines >> running thru them. I've tried getting screen shots but all I get is a >> solid black image off of any tool I try. Again the left head looks >> good the right is a black square. I guess I could take a pic with a >> digital camera if it would help. >> >> Not sure what component the would go under I'm assuming the radeon >> driver... >> >> BTW on i386, intel Pent 4 2.4ghz > > Can you file that in Xorg bugzilla, and CC me on it? Radeon 7000 > support seems to be deteriorating since FC3. ;/ > > TIA > I found an existing bug there I've updated and added you to the cc: per your request.... https://bugs.freedesktop.org/show_bug.cgi?id=5447 Pete -- Pete Graner email: Senior Manager Office: 978.392.2476 Base OS Engineering Mobile: 910.391.7621 Red Hat Inc. http://www.redhat.com From seandarcy2 at gmail.com Sat Feb 4 20:59:42 2006 From: seandarcy2 at gmail.com (sean) Date: Sat, 04 Feb 2006 15:59:42 -0500 Subject: Request for testers: Video hardware autodetection In-Reply-To: <43E4A50E.5070209@mharris.ca> References: <43E4A50E.5070209@mharris.ca> Message-ID: Mike A. Harris wrote: ................ Well maybe it worked. I have a radeon AIW 8500DV. system-config-display --reconfig assigned the radeon driver - so far so good, but described it as the "vendor supplied driver" for radeon (?). The list also showed the ati driver, which was also described as for radeon. In any event, for either the ati or radeon driver, system-config-display only showed 640x480 and 800x600. And, the i810 driver description does not show i945G ( I have another box with an i945 ). So it looks like the hardware is correctly detected, but system-config-display may need some tune up. sean From casimiro.barreto at gmail.com Sat Feb 4 21:04:54 2006 From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto) Date: Sat, 04 Feb 2006 19:04:54 -0200 Subject: Weird Yum Behaviour Message-ID: <43E516F6.6030901@gmail.com> An HTML attachment was scrubbed... URL: From drepper at redhat.com Sat Feb 4 21:12:26 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Sat, 04 Feb 2006 13:12:26 -0800 Subject: caution with latest kernel + glibc Message-ID: <43E518BA.3010207@redhat.com> Those who are running the current rawhide kernel and glibc (and coreutils or those trying to compile glibc for themselves) might find that their kernel locks up. One bug in this area (I think there is more than one) is fixed by the patch in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178558 The 1909 kernel and later will likely have the patch. For now it might be best to use glibc-2.3.90-30 and nothing later or alternatively live with the lockups for today. The fixed kernel is hopefully in tomorrow's rawhide. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From admin at ramshacklestudios.com Sat Feb 4 21:21:45 2006 From: admin at ramshacklestudios.com (Peter Gordon) Date: Sat, 04 Feb 2006 13:21:45 -0800 Subject: Xorg 6.9 Update for FC4? In-Reply-To: <43E47C9B.8040806@mharris.ca> References: <1139023771.3267.8.camel@tuxhugger> <43E47C9B.8040806@mharris.ca> Message-ID: <1139088105.3290.6.camel@tuxhugger> Alrighty. Thank you very much for the thorough explanation, Mike. =) -- Peter Gordon (codergeek42) GnuPG Public Key: 0xDA3634D7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From brugolsky at telemetry-investments.com Sat Feb 4 21:24:51 2006 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Sat, 4 Feb 2006 16:24:51 -0500 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <1139006387.2652.29.camel@bree.local.net> References: <1139006387.2652.29.camel@bree.local.net> Message-ID: <20060204212451.GA15094@ti64.telemetry-investments.com> On Fri, Feb 03, 2006 at 05:39:47PM -0500, Jeremy Katz wrote: > Although I hate to do it, it looks like we're going to have to slip > Fedora Core 5 test3 by a week. There is an ABI change in the gcc/glibc > stack that requires a rebuild of the entire distribution. Silly question: what lists/irc-channels do I need to subscribe to in order to see the technical discussion of ABI changes? Is this discussed primarily on the main gcc/glibc mail lists, or is there a more focused discussion elsewhere? [Trying to drink from the firehose that is lkml is difficult enough ...] Also, it would be helpful to include (links to) ABI compatibility information in the Release Notes sections for gcc/glibc. Regards, Bill Rugolsky From jakub at redhat.com Sat Feb 4 21:43:12 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Sat, 4 Feb 2006 16:43:12 -0500 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <20060204212451.GA15094@ti64.telemetry-investments.com> References: <1139006387.2652.29.camel@bree.local.net> <20060204212451.GA15094@ti64.telemetry-investments.com> Message-ID: <20060204214312.GT24295@devserv.devel.redhat.com> On Sat, Feb 04, 2006 at 04:24:51PM -0500, Bill Rugolsky Jr. wrote: > On Fri, Feb 03, 2006 at 05:39:47PM -0500, Jeremy Katz wrote: > > Although I hate to do it, it looks like we're going to have to slip > > Fedora Core 5 test3 by a week. There is an ABI change in the gcc/glibc > > stack that requires a rebuild of the entire distribution. > > Silly question: what lists/irc-channels do I need to subscribe to in > order to see the technical discussion of ABI changes? Is this discussed > primarily on the main gcc/glibc mail lists, or is there a more focused > discussion elsewhere? [Trying to drink from the firehose that is lkml > is difficult enough ...] The former. Se e.g.: http://sources.redhat.com/ml/libc-alpha/2006-01/msg00016.html http://sources.redhat.com/ml/libc-hacker/2006-01/msg00061.html http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01563.html http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01953.html http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01958.html etc. (many mails on all the 3 mailing lists). Jakub From ivg2 at cornell.edu Sat Feb 4 22:10:10 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Sat, 04 Feb 2006 17:10:10 -0500 Subject: Sessions and how to get rid of the RHN alert icon Message-ID: <43E52642.9070002@cornell.edu> I've heard this argument many times: "Windows starts up faster, then takes too long to load the systray applets, hence Linux is faster ". I haven't used Windows in a while, but my Linux experience is not very positive when it comes to applets - GNOME takes a long time to load them, and until they're all loaded the panel is unusable. Since all my startup icons are on the panel, I can't launch any applications. How is this any different? I blame the RHN alert icon. I don't know if it's the root of the problem, but I use rawhide, and I don't need an alert icon anyway. So, I'd like to get rid of it. However, it keeps coming back. If you click on Configuration -> Forward -> Remove from Panel, it disappears, but keeps coming back on every login. The same thing happens if you remove it from the Current Session. There used to be a checkbox "Save Session" on the Log Out button, but I don't see it anymore. How do I get rid of the icon, and save the session, so that it doesn't come back? From jonathansavage at gmail.com Sat Feb 4 22:19:03 2006 From: jonathansavage at gmail.com (Jon Savage) Date: Sat, 4 Feb 2006 14:19:03 -0800 Subject: Sessions and how to get rid of the RHN alert icon In-Reply-To: <43E52642.9070002@cornell.edu> References: <43E52642.9070002@cornell.edu> Message-ID: <2ad7cea10602041419g50734bb8md5778f94cd341c6e@mail.gmail.com> > I blame the RHN alert icon. I don't know if it's the root of the > problem, but I use rawhide, and I don't need an alert icon anyway. So, > I'd like to get rid of it. However, it keeps coming back. If you click > on Configuration -> Forward -> Remove from Panel, it disappears, but > keeps coming back on every login. The same thing happens if you remove > it from the Current Session. > > There used to be a checkbox "Save Session" on the Log Out button, but I > don't see it anymore. How do I get rid of the icon, and save the > session, so that it doesn't come back? chkconfig --level 0123456 rhnsd off should do the trick if memory serves From nicolas.mailhot at laposte.net Sat Feb 4 22:24:14 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 04 Feb 2006 23:24:14 +0100 Subject: Sessions and how to get rid of the RHN alert icon In-Reply-To: <43E52642.9070002@cornell.edu> References: <43E52642.9070002@cornell.edu> Message-ID: <1139091854.2866.6.camel@rousalka.dyndns.org> Le samedi 04 f?vrier 2006 ? 17:10 -0500, Ivan Gyurdiev a ?crit : > I've heard this argument many times: "Windows starts up faster, then > takes too long to load the systray applets, hence Linux is faster > ". I haven't used Windows in a while, but my Linux experience is not > very positive when it comes to applets - GNOME takes a long time to load > them, and until they're all loaded the panel is unusable. Since all my > startup icons are on the panel, I can't launch any applications. How is > this any different? My pet hate is gnome components (applets included) which load before parsing their gconf info, then realise they assumed the wrong settings and refresh two seconds later. (an easy way to reproduce this is to use different font settings - dpi, name, size than the system settings) The worst part are dialogs where buttons shift when the refresh occurs (gnome notices font settings are different - enlarges dialog - buttons are right-aligned and move right). Sometimes bad timing means one button is replaced by another while I'm clicking it (and remember the "safe" choice is the right one so when the ui move right the safe button is almost always replaced by a more dangerous one) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jspaleta at gmail.com Sat Feb 4 22:28:15 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 4 Feb 2006 17:28:15 -0500 Subject: Sessions and how to get rid of the RHN alert icon In-Reply-To: <43E52642.9070002@cornell.edu> References: <43E52642.9070002@cornell.edu> Message-ID: <604aa7910602041428p1909f43bmb070ecb512109dac@mail.gmail.com> On 2/4/06, Ivan Gyurdiev wrote: > There used to be a checkbox "Save Session" on the Log Out button, but I > don't see it anymore. How do I get rid of the icon, and save the > session, so that it doesn't come back? And since the Sessions preferences dialog still has a configurable switch for "ask at logout" you should definitely file a bug about the missing question at logout. Either the session preference dialog needs to remove the configuration option or the logout process needs to respect that configuration choice...either way its a bug. Poking at this a little more on my system.. i think there is perhaps a deeper bug with the sessions configuration. Starting from a system that doesn't have the rhn-applet package installed.. i installed it via yum.. started the process and then tried to get the rhn-applet to be part of my session. I can't get the rhn-applet to actually stay. its almost like the changes I make via the sessions preference are just being completely ignored. -jef From ivg2 at cornell.edu Sat Feb 4 22:33:01 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Sat, 04 Feb 2006 17:33:01 -0500 Subject: Sessions and how to get rid of the RHN alert icon In-Reply-To: <2ad7cea10602041419g50734bb8md5778f94cd341c6e@mail.gmail.com> References: <43E52642.9070002@cornell.edu> <2ad7cea10602041419g50734bb8md5778f94cd341c6e@mail.gmail.com> Message-ID: <43E52B9D.2050302@cornell.edu> > chkconfig --level 0123456 rhnsd off > should do the trick if memory serves > rhnsd is off, I am not subscribed to the Red Hat Network (the alert icon seems to work regardless). From ndbecker2 at gmail.com Sat Feb 4 22:33:51 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Sat, 04 Feb 2006 17:33:51 -0500 Subject: caution with latest kernel + glibc References: <43E518BA.3010207@redhat.com> Message-ID: Ulrich Drepper wrote: > Those who are running the current rawhide kernel and glibc (and > coreutils or those trying to compile glibc for themselves) might find > that their kernel locks up. One bug in this area (I think there is more > than one) is fixed by the patch in > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178558 > > The 1909 kernel and later will likely have the patch. For now it might > be best to use glibc-2.3.90-30 and nothing later or alternatively live > with the lockups for today. The fixed kernel is hopefully in tomorrow's > rawhide. > Any problem to run latest glibc with old kernel - e.g., 2.6.15-1.1863_FC5? The last few kernels won't run on this machine. BTW, I'm running this combination right now. From jspaleta at gmail.com Sat Feb 4 23:09:33 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 4 Feb 2006 18:09:33 -0500 Subject: Weird Yum Behaviour In-Reply-To: <43E516F6.6030901@gmail.com> References: <43E516F6.6030901@gmail.com> Message-ID: <604aa7910602041509r35a748d4wf7e68f363a221998@mail.gmail.com> On 2/4/06, Casimiro de Almeida Barreto wrote: > > Hello, > > Since yesterday yum (rawhide) is showing a weird behaviour: uses up to all > memory resources and dies... Freezes computer for about 4 hours (P4 at 2.8GHz > 512MB RAM (400MHz)). Enabled repositories are: devel & extras & dag discussed in the lists already and fixed with the python-sqlite package update. grab the python-sqlite package from the development mirrors and install it via rpm on the commandline. You want python-sqlite-1.1.6-3 -jef From michael.p.anderson at gmail.com Sun Feb 5 00:44:10 2006 From: michael.p.anderson at gmail.com (Michael Anderson) Date: Sat, 4 Feb 2006 18:44:10 -0600 Subject: Sessions and how to get rid of the RHN alert icon In-Reply-To: <43E52B9D.2050302@cornell.edu> References: <43E52642.9070002@cornell.edu> <2ad7cea10602041419g50734bb8md5778f94cd341c6e@mail.gmail.com> <43E52B9D.2050302@cornell.edu> Message-ID: I think removing it from the system all together would take care of the problem. rpm -e rpm-applet On 2/4/06, Ivan Gyurdiev wrote: > > > > chkconfig --level 0123456 rhnsd off > > should do the trick if memory serves > > > rhnsd is off, I am not subscribed to the Red Hat Network (the alert icon > seems to work regardless). > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From admin at ramshacklestudios.com Sun Feb 5 01:12:10 2006 From: admin at ramshacklestudios.com (Peter Gordon) Date: Sat, 04 Feb 2006 17:12:10 -0800 Subject: Sessions and how to get rid of the RHN alert icon In-Reply-To: References: <43E52642.9070002@cornell.edu> <2ad7cea10602041419g50734bb8md5778f94cd341c6e@mail.gmail.com> <43E52B9D.2050302@cornell.edu> Message-ID: <1139101930.3290.11.camel@tuxhugger> On Sat, 2006-02-04 at 18:44 -0600, Michael Anderson wrote: > I think removing it from the system all together would take care of > the problem. > rpm -e rpm-applet That's what I do as the very first thing after a fresh FC4 install. # yum remove '*rhn*' -- Peter Gordon (codergeek42) GnuPG Public Key: 0xDA3634D7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mailinglists at erwinrol.com Sun Feb 5 01:43:06 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sun, 05 Feb 2006 02:43:06 +0100 Subject: CD/DVD Burning Message-ID: <1139103787.3319.5.camel@xpc.home.erwinrol.com> I hate to bring it up after the mega thread on LKML, but I have some problems with CD burning. First of all what is the Fedora Core political correct program to burn CD/DVD under gnome ? I have been using k3b, but that's an evil KDE program ;-) Than when I try to re-burn an full CD-RW it gets automatically mounted, but the desktop context menu only has a "eject" entry, which is of no use, I need and "unmount" entry. Of course I wouldn't need that unmount entry when k3b would unmount the drive when I use the "unmount" menu entry that k3b offers, but that doesn't seem to do a thing. So i have to unmount by hand in a terminal window. Than the real trouble starts, I get interrupt lost messages, on a drive that used to work before. I already tried the acpi=noirq option without success. When trying the erase the disk, and burn and pretty much everything else that access the drive, i get the following errors; Feb 5 01:25:49 xpc kernel: ide-cd: cmd 0x3 timed out Feb 5 01:25:49 xpc kernel: hda: lost interrupt Feb 5 01:25:49 xpc kernel: hda: request sense failure: status=0x51 { DriveReady SeekComplete Error } Feb 5 01:25:49 xpc kernel: hda: request sense failure: error=0x40 { LastFailedSense=0x04 } Feb 5 01:26:49 xpc kernel: hda: lost interrupt Feb 5 01:27:51 xpc kernel: hda: lost interrupt Feb 5 01:28:53 xpc kernel: hda: lost interrupt Feb 5 01:29:55 xpc kernel: hda: lost interrupt Feb 5 01:30:57 xpc kernel: hda: lost interrupt The bad thing, is after this happens the machine pretty much has to be rebooted cause every program that now tries to access /dev/hda (for example a yum update kernel) hangs for ever in D-state. So is this one of the "bad luck, you bought wrong hardware again" cases ? I have seen reports like this that go back many years, and the keep coming bad, which sounds to me that there is no real solution. - Erwin PS: This is all with today's rawhide. From fedora at adslpipe.co.uk Sun Feb 5 03:03:09 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Sun, 05 Feb 2006 03:03:09 +0000 Subject: CD/DVD Burning In-Reply-To: <1139103787.3319.5.camel@xpc.home.erwinrol.com> References: <1139103787.3319.5.camel@xpc.home.erwinrol.com> Message-ID: <43E56AED.9060702@adslpipe.co.uk> Erwin Rol wrote: > I hate to bring it up after the mega thread on LKML, but I have some > problems with CD burning. I saw bits of it ... > First of all what is the Fedora Core political correct program to burn > CD/DVD under gnome ? I have been using k3b, but that's an evil KDE > program ;-) Well for burning .ISOs I right click and let nautilus do it for creating a "quick" CD with a few files on it, again nautilus CD/DVD creator is ok, just drag them in then click thw write button, but for "important" stuff where I want to verify after write and have more control over it, I use k3b, I think gnome-baker is eventually meant to allow us to stop using k3b :-) > Than the real trouble starts, I get interrupt lost messages, on a drive > that used to work before. I already tried the acpi=noirq option without > success. When trying the erase the disk, and burn and pretty much > everything else that access the drive, i get the following errors; only "hard" error I get from k3b is when trying to burn a DVD+RDL, but I'm now fairly convinved it is an issue with my drive/firmware :-( From mailinglists at erwinrol.com Sun Feb 5 03:39:03 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sun, 05 Feb 2006 04:39:03 +0100 Subject: CD/DVD Burning In-Reply-To: <1139103787.3319.5.camel@xpc.home.erwinrol.com> References: <1139103787.3319.5.camel@xpc.home.erwinrol.com> Message-ID: <1139110743.3319.22.camel@xpc.home.erwinrol.com> On Sun, 2006-02-05 at 02:43 +0100, Erwin Rol wrote: > Feb 5 01:25:49 xpc kernel: ide-cd: cmd 0x3 timed out > Feb 5 01:25:49 xpc kernel: hda: lost interrupt > Feb 5 01:25:49 xpc kernel: hda: request sense failure: status=0x51 { DriveReady SeekComplete Error } > Feb 5 01:25:49 xpc kernel: hda: request sense failure: error=0x40 { LastFailedSense=0x04 } > Feb 5 01:26:49 xpc kernel: hda: lost interrupt > Feb 5 01:27:51 xpc kernel: hda: lost interrupt I found these bugs one kernel.org; http://bugzilla.kernel.org/show_bug.cgi?id=5786 http://bugzilla.kernel.org/show_bug.cgi?id=4514 Those seem to be the same problems i have, and it is the same chipset, and in one case even the same Shuttle ST20G5 PC. The fedora bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178121 looks a bit like it to, but it doesn't talk about a specific chipset. The two kernel.org bugs are about the Ali M15x3 Chipset. Should i file a new bug ? - Erwin From bogdan.mustiata at gmail.com Sun Feb 5 05:43:34 2006 From: bogdan.mustiata at gmail.com (bogdan.mustiata at gmail.com) Date: Sun, 5 Feb 2006 07:43:34 +0200 Subject: CD/DVD Burning In-Reply-To: <43E56AED.9060702@adslpipe.co.uk> References: <1139103787.3319.5.camel@xpc.home.erwinrol.com> <43E56AED.9060702@adslpipe.co.uk> Message-ID: <200602050743.34202.bogdan.mustiata@gmail.com> On Sunday 05 February 2006 05:03, Andy Burns wrote: > Erwin Rol wrote: > > First of all what is the Fedora Core political correct program to burn > > CD/DVD under gnome ? I have been using k3b, but that's an evil KDE > > program ;-) > > Well for burning .ISOs I right click and let nautilus do it > for creating a "quick" CD with a few files on it, again nautilus CD/DVD > creator is ok, just drag them in then click thw write button, but for > "important" stuff where I want to verify after write and have more > control over it, I use k3b, I think gnome-baker is eventually meant to > allow us to stop using k3b :-) xcdroast is another EvilKDEFree(tm) program for you CD writer. From michael at knox.net.nz Sun Feb 5 05:59:02 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sun, 05 Feb 2006 18:59:02 +1300 Subject: CD/DVD Burning In-Reply-To: <200602050743.34202.bogdan.mustiata@gmail.com> References: <1139103787.3319.5.camel@xpc.home.erwinrol.com> <43E56AED.9060702@adslpipe.co.uk> <200602050743.34202.bogdan.mustiata@gmail.com> Message-ID: <1139119142.2765.3.camel@pingu.homenetwork.lan> On Sun, 2006-02-05 at 07:43 +0200, bogdan.mustiata at gmail.com wrote: > On Sunday 05 February 2006 05:03, Andy Burns wrote: > > Erwin Rol wrote: > > > First of all what is the Fedora Core political correct program to burn > > > CD/DVD under gnome ? I have been using k3b, but that's an evil KDE > > > program ;-) > > > > Well for burning .ISOs I right click and let nautilus do it > > for creating a "quick" CD with a few files on it, again nautilus CD/DVD > > creator is ok, just drag them in then click thw write button, but for > > "important" stuff where I want to verify after write and have more > > control over it, I use k3b, I think gnome-baker is eventually meant to > > allow us to stop using k3b :-) > > xcdroast is another EvilKDEFree(tm) program for you CD writer. > Why is GnomeBaker not installed by default in the Gnome install? k3b gets installed be default if you do a KDE install. Michael From admin at ramshacklestudios.com Sun Feb 5 06:59:44 2006 From: admin at ramshacklestudios.com (Peter Gordon) Date: Sat, 04 Feb 2006 22:59:44 -0800 Subject: CD/DVD Burning In-Reply-To: <1139119142.2765.3.camel@pingu.homenetwork.lan> References: <1139103787.3319.5.camel@xpc.home.erwinrol.com> <43E56AED.9060702@adslpipe.co.uk> <200602050743.34202.bogdan.mustiata@gmail.com> <1139119142.2765.3.camel@pingu.homenetwork.lan> Message-ID: <1139122784.10660.1.camel@tuxhugger> On Sun, 2006-02-05 at 18:59 +1300, Michael J Knox wrote: > Why is GnomeBaker not installed by default in the Gnome install? > > k3b gets installed be default if you do a KDE install. > > Michael GnomeBaker is currently being reviewed for Extras.[1] Once that is done, we will be able to submit an RFE for it to be added as part of Core (hopefully). [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170973 -- Peter Gordon (codergeek42) GnuPG Public Key: 0xDA3634D7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dimi at lattica.com Sun Feb 5 07:21:09 2006 From: dimi at lattica.com (Dimi Paun) Date: Sun, 05 Feb 2006 02:21:09 -0500 Subject: CD/DVD Burning In-Reply-To: <43E56AED.9060702@adslpipe.co.uk> References: <1139103787.3319.5.camel@xpc.home.erwinrol.com> <43E56AED.9060702@adslpipe.co.uk> Message-ID: <1139124070.26255.12.camel@dimi.lattica.com> On Sun, 2006-02-05 at 03:03 +0000, Andy Burns wrote: > Well for burning .ISOs I right click and let nautilus do it > for creating a "quick" CD with a few files on it, again nautilus > CD/DVD creator is ok, just drag them in then click thw write button, > but for "important" stuff where I want to verify after write and have > more control over it, I use k3b, I think gnome-baker is eventually > meant to allow us to stop using k3b :-) I tried to do the same, but every time I burned ISOs from nautilus, the result was corrupted (I only tried to burn the FC{34} ISOs, and then I checked them with anaconda's built-in tester). Of course, burning them with k3b (same box, same images, CDs from same batch) resulted in working CDs... Did anyone encounter the same behavior? -- Dimi Paun Lattica, Inc. From gnomeuser at gmail.com Sun Feb 5 07:26:23 2006 From: gnomeuser at gmail.com (David Nielsen) Date: Sun, 05 Feb 2006 08:26:23 +0100 Subject: caution with latest kernel + glibc In-Reply-To: <43E518BA.3010207@redhat.com> References: <43E518BA.3010207@redhat.com> Message-ID: <1139124384.3518.3.camel@price.stavtrup-st.dk> l?r, 04 02 2006 kl. 13:12 -0800, skrev Ulrich Drepper: > Those who are running the current rawhide kernel and glibc (and > coreutils or those trying to compile glibc for themselves) might find > that their kernel locks up. One bug in this area (I think there is more > than one) is fixed by the patch in > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178558 > > The 1909 kernel and later will likely have the patch. For now it might > be best to use glibc-2.3.90-30 and nothing later or alternatively live > with the lockups for today. The fixed kernel is hopefully in tomorrow's > rawhide. Would this explain why I appear to loose net connection periodically (on i386) following the latest update to glibc ? - David -- Obligatory shameless blog plug - the GNOME commentary located at: www.lovesunix.net/blog From nutello at sweetness.com Sun Feb 5 07:39:15 2006 From: nutello at sweetness.com (Rudi Chiarito) Date: Sun, 5 Feb 2006 08:39:15 +0100 Subject: CD/DVD Burning In-Reply-To: <1139124070.26255.12.camel@dimi.lattica.com> References: <1139103787.3319.5.camel@xpc.home.erwinrol.com> <43E56AED.9060702@adslpipe.co.uk> <1139124070.26255.12.camel@dimi.lattica.com> Message-ID: <20060205073915.GM20043@plain.rackshack.net> On Sun, Feb 05, 2006 at 02:21:09AM -0500, Dimi Paun wrote: > I tried to do the same, but every time I burned ISOs from nautilus, > the result was corrupted (I only tried to burn the FC{34} ISOs, > and then I checked them with anaconda's built-in tester). Of course, > burning them with k3b (same box, same images, CDs from same batch) > resulted in working CDs... > > Did anyone encounter the same behavior? I don't know if this is the same problem, but... last month I used Nautilus on my new FC4 laptop to burn a CD with a few pictures on them. I quickly checked the contents of the disc after burning it and it seemed fine. Days later, my brother tells me that the last few pictures had problems. He could see their names in the directory, but neither a PC nor a Mac could read the actual files. Of course I had tested only a random sample of the first pictures. That was the only CD I needed to burn in the past couple of years (I use the network otherwise), so I didn't think twice about it and blamed it on the media. A CD-R is so cheap these days that I just can't convince myself to trust it. Now I am having second thoughts; maybe it was nautilus (or the kernel) that messed up the final 4-5 MB of data. Ignoring the ISO checksum, can you actually compare the contents of the CD and its loop-mounted ISO image? You could use diff -qr to find out which files are to blame. cmp can tell you the offsets inside the files where the differences lie. -- Rudi From sdl.web at gmail.com Sun Feb 5 07:36:31 2006 From: sdl.web at gmail.com (leon) Date: Sun, 05 Feb 2006 07:36:31 +0000 Subject: where to report fc5 bug? Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is it bugzilla.fedora.us the right place? - -- _.---. _ Happy _/ __ >99. Dog (-. ,-.`(6666\ Year _ @| \@| )9999} <_>' `' /66666\ 2006 (^. {9999999) `-`.___/ }666666} ) {9999999) /,. \666666{ ,%%%\ `99999) ,%%%%%; `'~'\ %%%%%%%} `-._ %%%%%,' `-. ;%%%; ; \-. ;;`%; / _)`\ _;| ; ,'_ .-''''/ ((_j~_(,.,_;(((`._ /'''''/ (((___) ('''''( `".''') `.( -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD5asOUr+DnEUeM4oRAgwUAJ9F/3P+7V/EOmUFaysrf8ItigbKSQCgrG8e Taq0LwtVxyr3ffcVV+EPEUg= =pdEb -----END PGP SIGNATURE----- From jkeating at j2solutions.net Sun Feb 5 07:51:46 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 04 Feb 2006 23:51:46 -0800 Subject: where to report fc5 bug? In-Reply-To: References: Message-ID: <1139125907.3737.2.camel@ender> On Sun, 2006-02-05 at 07:36 +0000, leon wrote: > Is it bugzilla.fedora.us the right place? http://bugzilla.redhat.com is the correct place. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nmiell at comcast.net Sun Feb 5 08:01:35 2006 From: nmiell at comcast.net (Nicholas Miell) Date: Sun, 05 Feb 2006 00:01:35 -0800 Subject: where to report fc5 bug? In-Reply-To: References: Message-ID: <1139126495.3191.8.camel@entropy> On Sun, 2006-02-05 at 07:36 +0000, leon wrote: > Is it bugzilla.fedora.us the right place? .-. ( ) '-' J L | | J L | | J L .-'.___.'-. /___________\ _.-""' `bmw._ .' `. J `. F L J J J ` | L | | | | | J | L | | | ,.___ ___....--._ | ,' `""""""""' `-._ | J _____________________`-. | F .-' `-88888-' `Y8888b.`. | | .' `P' `88888b \ | | J # L # q8888b L | | | | )8888D ) | J \ J d8888P P | L `. .b. ,88888P / | `. `-.___,o88888o.___,o88888P'.' | `-.__________________________..-' | | | .-----.........____________J | .' | | | | ------------------------------ | J---|-----..|...___|_______| / \ | | | | | | < No, use bugzilla.redhat.com | | Y---|-----..|...___|_______| \ / | `. | | | | ------------------------------ | `'-------:....__|______.J | | L___ | """----...______________....--' -- Nicholas Miell From michael at knox.net.nz Sun Feb 5 08:42:51 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sun, 05 Feb 2006 21:42:51 +1300 Subject: CD/DVD Burning In-Reply-To: <1139122784.10660.1.camel@tuxhugger> References: <1139103787.3319.5.camel@xpc.home.erwinrol.com> <43E56AED.9060702@adslpipe.co.uk> <200602050743.34202.bogdan.mustiata@gmail.com> <1139119142.2765.3.camel@pingu.homenetwork.lan> <1139122784.10660.1.camel@tuxhugger> Message-ID: <1139128971.5562.2.camel@pingu.homenetwork.lan> On Sat, 2006-02-04 at 22:59 -0800, Peter Gordon wrote: > On Sun, 2006-02-05 at 18:59 +1300, Michael J Knox wrote: > > Why is GnomeBaker not installed by default in the Gnome install? > > > > k3b gets installed be default if you do a KDE install. > > > > Michael > > GnomeBaker is currently being reviewed for Extras.[1] Once that is done, > we will be able to submit an RFE for it to be added as part of Core > (hopefully). > > [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170973 Yes, I am well aware of it being in the review process, I guess I worded my question poorly. The point was meant to be more, why no Gnome CD app when there is a KDE app? There is no balance. Michael From gnomeuser at gmail.com Sun Feb 5 08:51:07 2006 From: gnomeuser at gmail.com (David Nielsen) Date: Sun, 05 Feb 2006 09:51:07 +0100 Subject: CD/DVD Burning In-Reply-To: <1139128971.5562.2.camel@pingu.homenetwork.lan> References: <1139103787.3319.5.camel@xpc.home.erwinrol.com> <43E56AED.9060702@adslpipe.co.uk> <200602050743.34202.bogdan.mustiata@gmail.com> <1139119142.2765.3.camel@pingu.homenetwork.lan> <1139122784.10660.1.camel@tuxhugger> <1139128971.5562.2.camel@pingu.homenetwork.lan> Message-ID: <1139129467.4544.0.camel@price.stavtrup-st.dk> s?n, 05 02 2006 kl. 21:42 +1300, skrev Michael J Knox: > On Sat, 2006-02-04 at 22:59 -0800, Peter Gordon wrote: > > On Sun, 2006-02-05 at 18:59 +1300, Michael J Knox wrote: > > > Why is GnomeBaker not installed by default in the Gnome install? > > > > > > k3b gets installed be default if you do a KDE install. > > > > > > Michael > > > > GnomeBaker is currently being reviewed for Extras.[1] Once that is done, > > we will be able to submit an RFE for it to be added as part of Core > > (hopefully). > > > > [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170973 > > Yes, I am well aware of it being in the review process, I guess I worded > my question poorly. > > The point was meant to be more, why no Gnome CD app when there is a KDE > app? Because audio burning is integrated in rhythmbox and data burning is in nautilus (via nautilus-cd-burner), the same with CD copying. - David -- Obligatory shameless blog plug - the GNOME commentary located at: www.lovesunix.net/blog From jfrieben at freesurf.fr Sun Feb 5 09:09:34 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Sun, 5 Feb 2006 10:09:34 +0100 (CET) Subject: Xorg 6.9 Update for FC4? In-Reply-To: <43E508B9.80702@gmx.net> References: <43E508B9.80702@gmx.net> Message-ID: <25327.194.94.224.254.1139130574.squirrel@arlette.freesurf.fr> No need to bother Mike: as I pointed out in my previuos comment, Xorg 6.9 packages for FC4 have already been created by various guys. The S/RPMS are freely available on the net. For instance, check: http://washington.kelkoo.net/epia/FC4 They were particularly built having the S3 Unichrome chip in mind but of course they will also work on other hardware. > Mike, if it helps, I'd love to be able to play with Xorg 6.9 on my FC4 > box, and I would be very appreciative of any time you wanted to spend > on creating some experimental rpms. > > Jonathan > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From ivg2 at cornell.edu Sun Feb 5 09:14:18 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Sun, 05 Feb 2006 04:14:18 -0500 Subject: Valgrind + Python: __strcpy_chk warning in PyImport_ImportModuleEx Message-ID: <43E5C1EA.5040309@cornell.edu> Can someone suggest the cause of this warning? Should I file a bug? Against python or glibc? This is python code being valgrind-ed on x86_64. The suppressions file here: http://svn.python.org/projects/python/trunk/Misc/ is installed, and additional suppressions for Memcheck:Value8 and Memcheck:Addr8 have been added in PyObject_Free and PyObject_Realloc. As a side node, why is this suppressions file not installed by default? ==16039== Conditional jump or move depends on uninitialised value(s) ==16039== at 0x37E2EDBBED: __strcpy_chk (in /lib64/libc-2.3.90.so) ==16039== by 0x3B9D79F3CB: (within /usr/lib64/libpython2.4.so.1.0) ==16039== by 0x3B9D7A1A2F: (within /usr/lib64/libpython2.4.so.1.0) ==16039== by 0x3B9D7A1DEF: (within /usr/lib64/libpython2.4.so.1.0) ==16039== by 0x3B9D7A1FA6: PyImport_ImportModuleEx (in /usr/lib64/libpython2.4.so.1.0) ==16039== by 0x3B9D784CFF: (within /usr/lib64/libpython2.4.so.1.0) ==16039== by 0x3B9D735E25: PyObject_Call (in /usr/lib64/libpython2.4.so.1.0) ==16039== by 0x3B9D787760: PyEval_CallObjectWithKeywords (in /usr/lib64/libpython2.4.so.1.0) ==16039== by 0x3B9D78A1D2: PyEval_EvalFrame (in /usr/lib64/libpython2.4.so.1.0) ==16039== by 0x3B9D78D701: PyEval_EvalCodeEx (in /usr/lib64/libpython2.4.so.1.0) ==16039== by 0x3B9D78D753: PyEval_EvalCode (in /usr/lib64/libpython2.4.so.1.0) ==16039== by 0x3B9D7A06B4: PyImport_ExecCodeModuleEx (in /usr/lib64/libpython2.4.so.1.0) From buildsys at redhat.com Sun Feb 5 09:52:39 2006 From: buildsys at redhat.com (Build System) Date: Sun, 5 Feb 2006 04:52:39 -0500 Subject: rawhide report: 20060205 changes Message-ID: <200602050952.k159qdce016612@porkchop.devel.redhat.com> Updated Packages: eclipse-1:3.1.2-1jpp_3fc ------------------------ * Sat Feb 04 2006 Ben Konrath 3.1.2-1jpp_3fc - Update efj patches to match what has been committed to HEAD. * Fri Feb 03 2006 Igor Foox 3.1.2-1jpp_2fc - Updated launcher script. * Tue Jan 31 2006 Andrew Overholt 3.1.2-1jpp_1fc - 3.1.2. - Remove unnecessary patches. glibc-2.3.90-36 --------------- * Sat Feb 04 2006 Jakub Jelinek 2.3.90-36 - update from CVS - fix frequency setting for ITIMER_PROF (#179938, BZ#2268) - fix powerpc inline fegetround () - fix nptl_db (#179946) gnome-media-2.13.91-2 --------------------- * Sat Feb 04 2006 Christopher Aillon - 2.13.91-2 - Use gstreamer (0.10) kdebindings-3.5.1-1 ------------------- kdeedu-3.5.1-1 -------------- * Sat Feb 04 2006 Than Ngo 3.5.1-1 - 3.5.1 kdegraphics-7:3.5.1-1 --------------------- * Sat Feb 04 2006 Than Ngo 7:3.5.1-1 - 3.5.1 kernel-2.6.15-1.1909_FC5 ------------------------ * Sat Feb 04 2006 Dave Jones - 2.6.16rc2-git1 - Fix deadlock in do_path_lookup() rhythmbox-0.9.3.1-1 ------------------- * Sat Feb 04 2006 Christopher Aillon 0.9.3.1-1 - Update to 0.9.3.1 - Use gstreamer (0.10) sound-juicer-2.13.4-2 --------------------- * Sat Feb 04 2006 Christopher Aillon 2.13.4-2 - Update to use gstreamer (0.10) xorg-x11-drv-i810-1.4.1.3-3 --------------------------- * Sat Feb 04 2006 Mike A. Harris 1.4.1.3-3 - Added 8086:2772 mapping to i810.xinf for bug (#178451) Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 sound-juicer - 2.13.4-2.i386 requires gstreamer-plugins Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs sound-juicer - 2.13.4-2.ia64 requires gstreamer-plugins Broken deps for ppc ---------------------------------------------------------- ccs-devel - 1.0.2-3.1.ppc requires ccs = 0:1.0.2-3.1 gulm - 1.0.4-2.FC5.1.ppc requires ccs sound-juicer - 2.13.4-2.ppc requires gstreamer-plugins Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 sound-juicer - 2.13.4-2.ppc64 requires gstreamer-plugins Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.4-2.s390 requires kernel >= 0:2.6.9-11 Broken deps for s390x ---------------------------------------------------------- libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) systemtap - 0.5.4-2.s390x requires kernel >= 0:2.6.9-11 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 sound-juicer - 2.13.4-2.x86_64 requires gstreamer-plugins From sdl.web at gmail.com Sun Feb 5 10:06:54 2006 From: sdl.web at gmail.com (leon) Date: Sun, 05 Feb 2006 10:06:54 +0000 Subject: fc5 test2 haldaemon failed? Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, Hal fail to start on system boot. Does anyone has similar experience? I'm going to file a bug if anyone confirm. And gnome powermanager applet failed too. It might have to do with hal. Run `/etc/init.d/haldaemon restart' gives: Stopping HAL daemon: [FAILED] Starting HAL daemon: [FAILED] - -- _.---. _ Happy _/ __ >99. Dog (-. ,-.`(6666\ Year _ @| \@| )9999} <_>' `' /66666\ 2006 (^. {9999999) `-`.___/ }666666} ) {9999999) /,. \666666{ ,%%%\ `99999) ,%%%%%; `'~'\ %%%%%%%} `-._ %%%%%,' `-. ;%%%; ; \-. ;;`%; / _)`\ _;| ; ,'_ .-''''/ ((_j~_(,.,_;(((`._ /'''''/ (((___) ('''''( `".''') `.( -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD5c5DKDqgm5pnsV8RAvfhAKCXH9B/w8tfFD1xxsRPW5Yfde3j6QCeK3/K Xbdm0ybSmsD0HAv5OEknc8U= =7Ob9 -----END PGP SIGNATURE----- From ggw at wolves.durham.nc.us Sun Feb 5 11:06:31 2006 From: ggw at wolves.durham.nc.us (G.Wolfe Woodbury) Date: Sun, 05 Feb 2006 06:06:31 -0500 Subject: Question about IT821x driver and DMA Message-ID: <20060205110631.GA6013@wolves.durham.nc.us> I actually have an ITE8212 with two 400GiB drives in a RAID1 configuration. It seems that I cannot set DMA with hdparm on this drive without driving the system into a lockup. >From what I could understand of the code, there are some significant DMA problems with the device, but there are a lot of workarounds present. The question is: am I doomed to PIO Mode on this device forever, or are y'all working actively to make real DMA work? The card locks the system hard when it fails, and it is prone to fail most frequently when trying to DMA and serve the data via SMB or NFS to other systems. I can practically guarantee that turning on DMA will kill the system in less than 1 minute if I attempt to turn it on with an active SMB session in progress. -- G.Wolfe Woodbury `- -' RHCT U The Line Eater is a boojum! From rodd at clarkson.id.au Sun Feb 5 11:43:21 2006 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Sun, 05 Feb 2006 22:43:21 +1100 Subject: CD/DVD Burning In-Reply-To: <20060205073915.GM20043@plain.rackshack.net> References: <1139103787.3319.5.camel@xpc.home.erwinrol.com> <43E56AED.9060702@adslpipe.co.uk> <1139124070.26255.12.camel@dimi.lattica.com> <20060205073915.GM20043@plain.rackshack.net> Message-ID: <1139139801.4191.2.camel@localhost.localdomain> On Sun, 2006-02-05 at 08:39 +0100, Rudi Chiarito wrote: > On Sun, Feb 05, 2006 at 02:21:09AM -0500, Dimi Paun wrote: > > I tried to do the same, but every time I burned ISOs from nautilus, > > the result was corrupted (I only tried to burn the FC{34} ISOs, > > and then I checked them with anaconda's built-in tester). Of course, > > burning them with k3b (same box, same images, CDs from same batch) > > resulted in working CDs... > > > > Did anyone encounter the same behavior? > > I don't know if this is the same problem, but... last month I used > Nautilus on my new FC4 laptop to burn a CD with a few pictures on them. > I quickly checked the contents of the disc after burning it and it > seemed fine. Days later, my brother tells me that the last few pictures > had problems. He could see their names in the directory, but neither a > PC nor a Mac could read the actual files. Of course I had tested only a > random sample of the first pictures. > > That was the only CD I needed to burn in the past couple of years (I > use the network otherwise), so I didn't think twice about it and blamed > it on the media. A CD-R is so cheap these days that I just can't > convince myself to trust it. Now I am having second thoughts; maybe it > was nautilus (or the kernel) that messed up the final 4-5 MB of data. > Ignoring the ISO checksum, can you actually compare the contents of the > CD and its loop-mounted ISO image? You could use diff -qr to find out > which files are to blame. cmp can tell you the offsets inside the files > where the differences lie. I've had similar problems. In my case, FC4 thinks my SATA DVD/CD burner is a ATA devices (sees it as hdc, not sdc) and when you burn too fast the drive can't keep up and does this. I've bugzilla'd this, but it's really and issue of the kernel not detecting my hardware properly and it's being resolved slowly. R. -- "It's a fine line between denial and faith. It's much better on my side" From aph at redhat.com Sun Feb 5 11:47:52 2006 From: aph at redhat.com (Andrew Haley) Date: Sun, 5 Feb 2006 11:47:52 +0000 Subject: Question about IT821x driver and DMA In-Reply-To: <20060205110631.GA6013@wolves.durham.nc.us> References: <20060205110631.GA6013@wolves.durham.nc.us> Message-ID: <17381.58856.859770.332584@zapata.pink> G.Wolfe Woodbury writes: > I actually have an ITE8212 with two 400GiB drives in a RAID1 > configuration. > > It seems that I cannot set DMA with hdparm on this drive without driving > the system into a lockup. > > >From what I could understand of the code, there are some significant DMA > problems with the device, but there are a lot of workarounds present. > > The question is: am I doomed to PIO Mode on this device forever, or are > y'all working actively to make real DMA work? Works for me: Jan 31 16:21:11 zorro kernel: IT8212: IDE controller at PCI slot 0000:00:09.0 Jan 31 16:21:11 zorro kernel: ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 Jan 31 16:21:11 zorro kernel: PCI: setting IRQ 11 as level-triggered Jan 31 16:21:11 zorro kernel: ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11 Jan 31 16:21:11 zorro kernel: IT8212: chipset revision 19 Jan 31 16:21:11 zorro kernel: it821x: controller in pass through mode. Jan 31 16:21:11 zorro kernel: IT8212: 100% native mode on irq 11 Jan 31 16:21:11 zorro kernel: ide0: BM-DMA at 0xbc00-0xbc07, BIOS settings: hda:pio, hdb:DMA Jan 31 16:21:12 zorro kernel: hda: max request size: 1024KiB Jan 31 16:21:12 zorro kernel: hda: 488397168 sectors (250059 MB) w/7938KiB Cache, CHS=30401/255/63, UDMA(100) Jan 31 16:21:12 zorro kernel: hda: cache flushes supported Jan 31 16:21:12 zorro kernel: hda: hda1 hda2 hda3 hda4 < hda5 hda6 > Jan 31 16:21:12 zorro kernel: hdb: max request size: 1024KiB Jan 31 16:21:12 zorro kernel: hdb: 312581808 sectors (160041 MB) w/8192KiB Cache, CHS=19457/255/63, UDMA(100) Jan 31 16:21:12 zorro kernel: hdb: cache flushes supported Jan 31 16:21:12 zorro kernel: hdb: hdb1 hdb2 Andrew. From mailinglists at erwinrol.com Sun Feb 5 12:22:29 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sun, 05 Feb 2006 13:22:29 +0100 Subject: login out Message-ID: <1139142149.3319.39.camel@xpc.home.erwinrol.com> I have a problem loging out from X. when i sellect logout i get a dialog asking if i want to, when i click OK i get a dialog "Session Saved" and when i click OK (the only option) the dialog goes away but i jsut stay logged in, as if nothing happened. - Erwin From naoki at valuecommerce.com Sun Feb 5 13:34:49 2006 From: naoki at valuecommerce.com (Naoki) Date: Sun, 05 Feb 2006 22:34:49 +0900 Subject: fc5 test2 haldaemon failed? In-Reply-To: References: Message-ID: <43E5FEF9.20504@valuecommerce.com> Funnily enough (or not) I have the same problem. Never really bothered to check why though as my system seems fine and I though it was just me. Now I know there might be something to it I had a look.. Startup fails here : + /bin/bash -c 'ulimit -S -c 0 >/dev/null 2>&1 ; hald --retain-privileges' + '[' 1 -eq 0 ']' + failure 'haldaemon startup' + rc=1 + '[' color '!=' verbose -a -z '' ']' + echo_failure Running an strace over the process shows _many_ of these : [pid 19360] fcntl64(585, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor) [pid 19360] fcntl64(586, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor) [pid 19360] fcntl64(587, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor) [pid 19360] fcntl64(588, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor) [pid 19360] fcntl64(589, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor) [pid 19360] fcntl64(590, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor) [pid 19360] fcntl64(591, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor) [pid 19360] fcntl64(592, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor) Along with about a few million lines of other output which I have no idea the meaning of. leon wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > > Hal fail to start on system boot. Does anyone has similar experience? > I'm going to file a bug if anyone confirm. And gnome powermanager applet > failed too. It might have to do with hal. > > Run `/etc/init.d/haldaemon restart' gives: > > Stopping HAL daemon: [FAILED] > Starting HAL daemon: [FAILED] From pbrobinson at gmail.com Sun Feb 5 13:46:59 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Sun, 5 Feb 2006 13:46:59 +0000 Subject: rawhide report: 20060205 changes In-Reply-To: <200602050952.k159qdce016612@porkchop.devel.redhat.com> References: <200602050952.k159qdce016612@porkchop.devel.redhat.com> Message-ID: <5256d0b0602050546t302ae7b7nec462880aad14d47@mail.gmail.com> > sound-juicer-2.13.4-2 > --------------------- > * Sat Feb 04 2006 Christopher Aillon 2.13.4-2 > - Update to use gstreamer (0.10) This needs the deps to be updated to gstreamer-plugins-base from gstreamer-plugins Pete From linux_4ever at yahoo.com Sun Feb 5 13:55:18 2006 From: linux_4ever at yahoo.com (Steve G) Date: Sun, 5 Feb 2006 05:55:18 -0800 (PST) Subject: Valgrind + Python: __strcpy_chk warning in PyImport_ImportModuleEx In-Reply-To: <43E5C1EA.5040309@cornell.edu> Message-ID: <20060205135518.50797.qmail@web51501.mail.yahoo.com> >==16039== at 0x37E2EDBBED: __strcpy_chk (in /lib64/libc-2.3.90.so) >==16039== by 0x3B9D79F3CB: (within /usr/lib64/libpython2.4.so.1.0) >==16039== by 0x3B9D7A1A2F: (within /usr/lib64/libpython2.4.so.1.0) >==16039== by 0x3B9D7A1DEF: (within /usr/lib64/libpython2.4.so.1.0) If you ran this against libpython with the debug symbols still in it, it would be more meaningful. Usually, these are easy to fix when you see the function calls. I'd build python again and try to run your script against python in the build dir since that should still have the debug symbols. (You can use nm to verify.) LD_PRELOAD might be used to load libpython from the builddir, too. Without debug symbols, valgrind only tells you there's a problem - but not where to fix it. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From avi at argo.co.il Sun Feb 5 14:51:23 2006 From: avi at argo.co.il (Avi Kivity) Date: Sun, 05 Feb 2006 16:51:23 +0200 Subject: fc5 test2 haldaemon failed? In-Reply-To: <43E5FEF9.20504@valuecommerce.com> References: <43E5FEF9.20504@valuecommerce.com> Message-ID: <43E610EB.1080001@argo.co.il> Naoki wrote: > > Running an strace over the process shows _many_ of these : > > [pid 19360] fcntl64(585, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file > descriptor) [...] > [pid 19360] fcntl64(592, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file > descriptor) > this is normal unix braindamage, nothing to worry about. the process wants to prevent file descriptors from leaking into its children. > > Along with about a few million lines of other output which I have no > idea the meaning of. > try running hald with --verbose > > leon wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi all, >> >> Hal fail to start on system boot. Does anyone has similar experience? >> I'm going to file a bug if anyone confirm. And gnome powermanager applet >> failed too. It might have to do with hal. >> >> Run `/etc/init.d/haldaemon restart' gives: >> >> Stopping HAL daemon: [FAILED] >> Starting HAL daemon: [FAILED] > > -- error compiling committee.c: too many arguments to function From sundaram at fedoraproject.org Sun Feb 5 16:21:27 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 05 Feb 2006 21:51:27 +0530 Subject: Proposed and major updates policy In-Reply-To: <200602041319.03294.lamont@gurulabs.com> References: <43E4AC9E.2050907@fedoraproject.org> <200602041304.19683.lamont@gurulabs.com> <43E50A71.9060905@mharris.ca> <200602041319.03294.lamont@gurulabs.com> Message-ID: <43E62607.9070807@fedoraproject.org> Hi > > > >>I don't have the stats, but I would guess that if they were >>separate lists, less people would be on the announce list than >>on the test list, and there's already a deficit of people using >>updates-testing. To increase that, announcements should hit >>as many people as possible. Perhaps posting them to redhat-list, >>and fedora-list too. ;) Ok, maybe that's too much.. :) >> >> > >Well, the reason I'm not subscribed to fedora-test-list is that there is way >too much going on there leading up to test1 and going through until release >for each release. If fedora-updates-testing-list & fedora-test-list (for >testX releases) were separate, that might help get more people on boeard for >update testing. > > It's pretty easy to set up filters to check for announcements based on the subject or the sender. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From sundaram at fedoraproject.org Sun Feb 5 16:26:03 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 05 Feb 2006 21:56:03 +0530 Subject: where to report fc5 bug? In-Reply-To: References: Message-ID: <43E6271B.4000300@fedoraproject.org> leon wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Is it bugzilla.fedora.us the right place? >- -- > FC5 is not released yet. If you see the homepage of http://fedora.us you might notice the status of the site. http://bugzilla.redhat.com fedora-devel is the place to report bugs in the current development tree. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From caillon at redhat.com Sun Feb 5 16:40:04 2006 From: caillon at redhat.com (Christopher Aillon) Date: Sun, 05 Feb 2006 11:40:04 -0500 Subject: where to report fc5 bug? In-Reply-To: <43E6271B.4000300@fedoraproject.org> References: <43E6271B.4000300@fedoraproject.org> Message-ID: <43E62A64.6020904@redhat.com> On 02/05/2006 11:26 AM, Rahul Sundaram wrote: > FC5 is not released yet. If you see the homepage of http://fedora.us you > might notice the status of the site. Wow, its 7 months into the future. Now if we could only get it to tell us when FC5 is going to be released... --- UPDATE! September 6th, 2006: Effective immediately RH8 Extras will no longer be maintained. UPDATE! September 10, 2006: Effective immediately FC3 apt repositories are removed, read below. From igorm5 at vip.hr Sun Feb 5 16:47:22 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Sun, 05 Feb 2006 17:47:22 +0100 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <200602041315.27763.lamont@gurulabs.com> References: <1139006387.2652.29.camel@bree.local.net> <200602041255.23869.lamont@gurulabs.com> <43E5095E.3060804@mharris.ca> <200602041315.27763.lamont@gurulabs.com> Message-ID: <43E62C1A.7000402@vip.hr> Lamont R. Peterson wrote: > On Saturday 04 February 2006 01:06pm, Mike A. Harris wrote: >>Lamont R. Peterson wrote: >>I think our 6 month cycle plan remains, but will likely vary depending >>on various factors. I'd like to see it be a 9 month cycle that can >>vary earlier or later though, but that's just my personal opinion. I >>dunno who else would agree with me on that. ;) > Now that you mention it, I like it. I would support the idea. I like it too. Which means 1 or 2 releases a year. Seems enough time to make a stable release. -- Igor Jagec From fedora at leemhuis.info Sun Feb 5 16:49:48 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 05 Feb 2006 17:49:48 +0100 Subject: Proposed and major updates policy In-Reply-To: <43E62607.9070807@fedoraproject.org> References: <43E4AC9E.2050907@fedoraproject.org> <200602041304.19683.lamont@gurulabs.com> <43E50A71.9060905@mharris.ca> <200602041319.03294.lamont@gurulabs.com> <43E62607.9070807@fedoraproject.org> Message-ID: <1139158188.2948.30.camel@localhost.localdomain> Am Sonntag, den 05.02.2006, 21:51 +0530 schrieb Rahul Sundaram: > >>I don't have the stats, but I would guess that if they were > >>separate lists, less people would be on the announce list than > >>on the test list, and there's already a deficit of people using > >>updates-testing. To increase that, announcements should hit > >>as many people as possible. Perhaps posting them to redhat-list, > >>and fedora-list too. ;) Ok, maybe that's too much.. :) > >Well, the reason I'm not subscribed to fedora-test-list is that there is way > >too much going on there leading up to test1 and going through until release > >for each release. If fedora-updates-testing-list & fedora-test-list (for > >testX releases) were separate, that might help get more people on boeard for > >update testing. > > It's pretty easy to set up filters to check for announcements based on > the subject or the sender. This is far from perfect solution. Easy example: - you filter for "Fedora Core . Test Update", all other mail is routed to /dev/null from fedora-test-list - "Fedora Core 4 Test Update: udev-071-0.FC4.2" is posted and you get it - someone else does it wrong and posts a mail with the subject "Problems with udev from updates testing" (people will do that, that's life) -- a lengthy thread might result from it and you'll miss it because only /dev/null can read it. Okay, you can try also to filter for "updates testing" and "FC4", but you will still miss some relevant discussions. :-| IMHO a separate mailinglist for updates-testing would be a good idea -- I would subscribe. BTW, I really like the idea that started this thread (the "Can we have a policy to ensure to that all the updates have a week or so of testing period in the updates-testing repository with the exception of security updates which go through a shorter duration of testing?." idea) CU thl -- Thorsten Leemhuis From arjan at fenrus.demon.nl Sun Feb 5 16:59:56 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sun, 05 Feb 2006 17:59:56 +0100 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <200602041157.17339.prigault@oricom.ca> References: <200602041157.17339.prigault@oricom.ca> Message-ID: <1139158796.3131.44.camel@laptopd505.fenrus.org> > I am also very concerned about the delay in the release of GCC-4.1 (no release > candidate yet), expecting FC5-final to include a compiler that has a wide > level of exposure to testing. Having GCC-4.1-cvs-xxx would make users > uncomfortable, and without bringing back the old RedHat ghost of gcc-2.96, I > remind you that FC4 was released with a compiler blacklisted by the KDE > project, which incidentally was one of the reasons for me and my institution > to skip FC4 altogether and stay with FC3 until FC5 is released. That doesn't show a lot of knowledge on your institutions part though ;( KDE blacklisted that gcc for ONE bug, a bug fixed in the RH rpms already. From drepper at redhat.com Sun Feb 5 17:40:13 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Sun, 05 Feb 2006 09:40:13 -0800 Subject: caution with latest kernel + glibc In-Reply-To: <1139124384.3518.3.camel@price.stavtrup-st.dk> References: <43E518BA.3010207@redhat.com> <1139124384.3518.3.camel@price.stavtrup-st.dk> Message-ID: <43E6387D.8060403@redhat.com> David Nielsen wrote: > Would this explain why I appear to loose net connection periodically (on > i386) following the latest update to glibc ? No. The effects of the bug are that filesystem operations block without ever recovering. If a popular partition is affected the whole system will come to a standstill). -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From drepper at redhat.com Sun Feb 5 17:45:57 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Sun, 05 Feb 2006 09:45:57 -0800 Subject: Valgrind + Python: __strcpy_chk warning in PyImport_ImportModuleEx In-Reply-To: <43E5C1EA.5040309@cornell.edu> References: <43E5C1EA.5040309@cornell.edu> Message-ID: <43E639D5.1020006@redhat.com> Ivan Gyurdiev wrote: > Should I file a bug? Against python or glibc? Probably against neither. These bugs, especially when the highly optimized strings functions are involved, are most of the time problems with valgrind's heuristics and need to be whitelisted. You probably need to look at the code and determine whether there is a problem and if not, add an exception to the python exception file (if there is one). -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From dimi at lattica.com Sun Feb 5 18:34:01 2006 From: dimi at lattica.com (Dimi Paun) Date: Sun, 05 Feb 2006 13:34:01 -0500 Subject: CD/DVD Burning In-Reply-To: <1139139801.4191.2.camel@localhost.localdomain> References: <1139103787.3319.5.camel@xpc.home.erwinrol.com> <43E56AED.9060702@adslpipe.co.uk> <1139124070.26255.12.camel@dimi.lattica.com> <20060205073915.GM20043@plain.rackshack.net> <1139139801.4191.2.camel@localhost.localdomain> Message-ID: <1139164441.26255.25.camel@dimi.lattica.com> On Sun, 2006-02-05 at 22:43 +1100, Rodd Clarkson wrote: > I've had similar problems. In my case, FC4 thinks my SATA DVD/CD > burner is a ATA devices (sees it as hdc, not sdc) and when you burn > too fast the drive can't keep up and does this. But does it work properly from k3b, but not from nautilus? This is what is really confusing in my case... -- Dimi Paun Lattica, Inc. From sdl.web at gmail.com Sun Feb 5 18:48:39 2006 From: sdl.web at gmail.com (leon) Date: Sun, 05 Feb 2006 18:48:39 +0000 Subject: fc5 test2 haldaemon failed? References: <43E5FEF9.20504@valuecommerce.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Good to know. Well, I have found a funny solution. If I disable SElinux, then both `Avahi daemon' and `haldaemon' will run happily. - -- _.---. _ Happy _/ __ >99. Dog (-. ,-.`(6666\ Year _ @| \@| )9999} <_>' `' /66666\ 2006 (^. {9999999) `-`.___/ }666666} ) {9999999) /,. \666666{ ,%%%\ `99999) ,%%%%%; `'~'\ %%%%%%%} `-._ %%%%%,' `-. ;%%%; ; \-. ;;`%; / _)`\ _;| ; ,'_ .-''''/ ((_j~_(,.,_;(((`._ /'''''/ (((___) ('''''( `".''') `.( -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD5kiKKDqgm5pnsV8RAlUTAJ4oUsXWFemC3jZprvdp0IB4DcJ17QCglj4H G/gPX64ZLAuU+EGfRQEafvs= =Q1+a -----END PGP SIGNATURE----- From jkeating at j2solutions.net Sun Feb 5 18:55:39 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 05 Feb 2006 10:55:39 -0800 Subject: fc5 test2 haldaemon failed? In-Reply-To: References: <43E5FEF9.20504@valuecommerce.com> Message-ID: <1139165740.3737.6.camel@ender> On Sun, 2006-02-05 at 18:48 +0000, leon wrote: > Happy Can you please use a smaller sig when posting to a public email list? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sdl.web at gmail.com Sun Feb 5 19:24:02 2006 From: sdl.web at gmail.com (leon) Date: Sun, 05 Feb 2006 19:24:02 +0000 Subject: fc5 test2 haldaemon failed? References: <43E5FEF9.20504@valuecommerce.com> <1139165740.3737.6.camel@ender> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 How about this? Jesse Keating writes: | On Sun, 2006-02-05 at 18:48 +0000, leon wrote: | > Happy | | Can you please use a smaller sig when posting to a public email list? | | -- | Jesse Keating RHCE (geek.j2solutions.net) | Fedora Legacy Team (www.fedoralegacy.org) | GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) | -- | fedora-devel-list mailing list | fedora-devel-list at redhat.com | https://www.redhat.com/mailman/listinfo/fedora-devel-list - -- .--~~,__ :-....,-------`~~'._.' Dog's year! `-,,, ,_ ;'~U' _,-' ,'`-__; '--. (_/'~~ ''''(; -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD5lDUKDqgm5pnsV8RAo8EAJ9I/lI2DkAgIvOS4sUJA9omYn5LWACeIpfX jRp2xRU5l+vVE7mXWU+PTsk= =7iT8 -----END PGP SIGNATURE----- From gnomeuser at gmail.com Sun Feb 5 19:40:33 2006 From: gnomeuser at gmail.com (David Nielsen) Date: Sun, 05 Feb 2006 20:40:33 +0100 Subject: caution with latest kernel + glibc In-Reply-To: <43E6387D.8060403@redhat.com> References: <43E518BA.3010207@redhat.com> <1139124384.3518.3.camel@price.stavtrup-st.dk> <43E6387D.8060403@redhat.com> Message-ID: <1139168433.2350.4.camel@price.stavtrup-st.dk> s?n, 05 02 2006 kl. 09:40 -0800, skrev Ulrich Drepper: > David Nielsen wrote: > > Would this explain why I appear to loose net connection periodically (on > > i386) following the latest update to glibc ? > > No. The effects of the bug are that filesystem operations block without > ever recovering. If a popular partition is affected the whole system > will come to a standstill). It turned out after a bit of debugging effort to be the router that was behaving badly. - David -- Obligatory shameless blog plug - the GNOME commentary located at: www.lovesunix.net/blog From canfield at uindy.edu Sun Feb 5 22:03:38 2006 From: canfield at uindy.edu (D Canfield) Date: Sun, 05 Feb 2006 17:03:38 -0500 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <43E5095E.3060804@mharris.ca> References: <1139006387.2652.29.camel@bree.local.net> <1139014200.2863.65.camel@yoda.loki.me> <43E48DDD.4060508@vip.hr> <200602041255.23869.lamont@gurulabs.com> <43E5095E.3060804@mharris.ca> Message-ID: <43E6763A.8050509@uindy.edu> Mike A. Harris wrote: > > I think our 6 month cycle plan remains, but will likely vary depending > on various factors. I'd like to see it be a 9 month cycle that can > vary earlier or later though, but that's just my personal opinion. I > dunno who else would agree with me on that. ;) > Perhaps this is just my own experience and impressions, but through the RHL releases and even as recently as the first couple of FC releases, I was always eagerly awaiting each new release because of various great improvements that made the system more generally usable. As tired as I would get of constantly rebuilding my machine, I would install most of the test releases just because I wanted those features that badly. With FC 3 & 4, my "appetite" for new releases has slowed down significantly, and the only reason I look for betas nowadays is usually support for newer hardware. In fact, the only two things I'm eager for in FC5 are a working suspend on my thinkpad, and evolution syncing on my Treo (neither of which looks is looking too promising anymore). The point of all that is to say that I think as FC and Linux/OSS mature, there will be less demand for a steady stream of updates, and a 9-12 month release cycle would probably be quite acceptable. In fact, if things go the direction they seem to be, most people would probably prefer a longer-lived Core infrastructure, and look more to Extras for faster-moving updates to day-to-day apps. Just my perception. DC From tmus at tmus.dk Sun Feb 5 22:04:14 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Sun, 05 Feb 2006 23:04:14 +0100 Subject: login out In-Reply-To: <1139142149.3319.39.camel@xpc.home.erwinrol.com> References: <1139142149.3319.39.camel@xpc.home.erwinrol.com> Message-ID: Erwin Rol wrote: > I have a problem loging out from X. when i sellect logout i get a dialog > asking if i want to, when i click OK i get a dialog "Session Saved" and > when i click OK (the only option) the dialog goes away but i jsut stay > logged in, as if nothing happened. > > - Erwin > > I've noticed this too a few times - seems to happen what I haven't terminated all applications. A few times i've dismissed my experience, thinking that i'd probably mistakenly hit the save session checkbox - But I know I haven't - not alle of the times! /Thomas From seg at haxxed.com Sun Feb 5 23:02:21 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 05 Feb 2006 17:02:21 -0600 Subject: e1000 in rawhide kernel In-Reply-To: <200602031302.39171.lamont@gurulabs.com> References: <1138925360.3728.5.camel@nemausa.et.endace.com> <1138957442.21385.2.camel@localhost.localdomain> <5256d0b0602030116l2f1415daofaa13ab36f7d22f3@mail.gmail.com> <200602031302.39171.lamont@gurulabs.com> Message-ID: <1139180542.5067.12.camel@localhost.localdomain> On Fri, 2006-02-03 at 13:02 -0700, Lamont R. Peterson wrote: > On the machine with this firewall config, try to "ifup" your DHCP > interface(s). Notice how it works? Netfilter will never block DHCP > client-side (I've never tested this filewall config on the DHCP server; my > first inclination is to expect that you could still get DHCP, but maybe not). > > Remember, there are *no* rules in this config allowing traffic of *any* kind. > And yet, DHCP still works. This is an intentional feature in Netfilter. Not really. Has nothing to do with netfilter. Many dhcp clients (like ISC's) operate by using packet sockets to send/receive raw ethernet frames, which completely bypasses the kernel's IPv4 stack, netfilter and all. Its not a netfilter "feature". IIRC, DHCP server daemons tend to do this as well. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wtogami at redhat.com Mon Feb 6 01:31:27 2006 From: wtogami at redhat.com (Warren Togami) Date: Mon, 06 Feb 2006 10:31:27 +0900 Subject: Proposed and major updates policy In-Reply-To: <1139070457.7617.13.camel@gilboa-home-dev.localhost> References: <43E4AC9E.2050907@fedoraproject.org> <1139070457.7617.13.camel@gilboa-home-dev.localhost> Message-ID: <43E6A6EF.4020008@redhat.com> Gilboa Davara wrote: > I second that. > The lack of FC package update policy is a real pain in the back side. > The KDE 3.5.x release backlash was just an example of why such a policy > must be set. > IMHO, the vast majority of updates have been no problem. KDE however has been a bit problematic in particular. Upgrading such a large group of packages is reckless especially when done without testing. Unfortunately, I am afraid some developers do not test new updates before pushing. I believe we don't need any strict policy like "a week in testing" repository because the majority of updates are really no problem. We should however say "test it and be sure it works, and if you are less sure put it in testing". Also bigger updates like an entire new KDE release definitely must go into testing. Requiring ALL updates to go into the testing repository will unnecessary slow down progress. Warren Togami wtogami at redhat.com From jspaleta at gmail.com Mon Feb 6 01:55:01 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 5 Feb 2006 20:55:01 -0500 Subject: Proposed and major updates policy In-Reply-To: <1139158188.2948.30.camel@localhost.localdomain> References: <43E4AC9E.2050907@fedoraproject.org> <200602041304.19683.lamont@gurulabs.com> <43E50A71.9060905@mharris.ca> <200602041319.03294.lamont@gurulabs.com> <43E62607.9070807@fedoraproject.org> <1139158188.2948.30.camel@localhost.localdomain> Message-ID: <604aa7910602051755y1ac6e85uaa9164f33b26fe5f@mail.gmail.com> On 2/5/06, Thorsten Leemhuis wrote: > This is far from perfect solution. Easy example: The PERFECT solution.. is to integrate update notifications back into available client tools.. so noone has to dink around with any mailinglist at all to see update annoucements. In the perfect world, all you have to do is ask your client tool to give you a summary of relevant notifications for each repo you are interested in from the repo metadata. Trying to figure out how to sprinkle annoucements into the mailinglists is just a huge waste of everyones brainpower. mailinglists are not the right solution for this information no matter if you decide to put them in their own mailinglist or not. The right solution is to get notification text directly coupled into the workflow of package updating and package discovery. You are just picking nits when you are trying to decide whether test-list is the best mailinglist. -jef"how about we just have one mailinglist for every package...that includes notifications and bugreports and development discussion for that one particular package. That way i dont have to see any discussion about kde updates because I don't install or use kde. So what if we'd end up with thousands of mailinglists.. what's really important is making sure noone sees a single discussion they are not interested in seeing"spaleta > - you filter for "Fedora Core . Test Update", all other mail is routed > to /dev/null from fedora-test-list > - "Fedora Core 4 Test Update: udev-071-0.FC4.2" is posted and you get it > - someone else does it wrong and posts a mail with the subject "Problems > with udev from updates testing" (people will do that, that's life) -- a > lengthy thread might result from it and you'll miss it because > only /dev/null can read it. > > Okay, you can try also to filter for "updates testing" and "FC4", but > you will still miss some relevant discussions. :-| > > IMHO a separate mailinglist for updates-testing would be a good idea -- > I would subscribe. > > BTW, I really like the idea that started this thread (the "Can we have a > policy to ensure to that all the updates have a week or so of testing > period in the updates-testing repository with the exception of security > updates which go through a shorter duration of testing?." idea) > > CU > thl > -- > Thorsten Leemhuis > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From wtogami at redhat.com Mon Feb 6 02:09:04 2006 From: wtogami at redhat.com (Warren Togami) Date: Mon, 06 Feb 2006 11:09:04 +0900 Subject: Proposed and major updates policy In-Reply-To: <604aa7910602051755y1ac6e85uaa9164f33b26fe5f@mail.gmail.com> References: <43E4AC9E.2050907@fedoraproject.org> <200602041304.19683.lamont@gurulabs.com> <43E50A71.9060905@mharris.ca> <200602041319.03294.lamont@gurulabs.com> <43E62607.9070807@fedoraproject.org> <1139158188.2948.30.camel@localhost.localdomain> <604aa7910602051755y1ac6e85uaa9164f33b26fe5f@mail.gmail.com> Message-ID: <43E6AFC0.3010308@redhat.com> Jeff Spaleta wrote: > On 2/5/06, Thorsten Leemhuis wrote: >> This is far from perfect solution. Easy example: > > The PERFECT solution.. is to integrate update notifications back into > available client tools.. so noone has to dink around with any > mailinglist at all to see update annoucements. In the perfect world, > all you have to do is ask your client tool to give you a summary of > relevant notifications for each repo you are interested in from the > repo metadata. I strongly agree that users shouldn't need to fumble through mail in order to read update announcements. This should be part of our package metadata and easily browsable using package management tools. Warren Togami wtogami at redhat.com From lmacken at redhat.com Mon Feb 6 03:01:04 2006 From: lmacken at redhat.com (Luke Macken) Date: Sun, 5 Feb 2006 22:01:04 -0500 Subject: Proposed and major updates policy In-Reply-To: <43E6AFC0.3010308@redhat.com> References: <43E4AC9E.2050907@fedoraproject.org> <200602041304.19683.lamont@gurulabs.com> <43E50A71.9060905@mharris.ca> <200602041319.03294.lamont@gurulabs.com> <43E62607.9070807@fedoraproject.org> <1139158188.2948.30.camel@localhost.localdomain> <604aa7910602051755y1ac6e85uaa9164f33b26fe5f@mail.gmail.com> <43E6AFC0.3010308@redhat.com> Message-ID: <20060206030104.GA25248@tomservo.boston.redhat.com> On Mon, Feb 06, 2006 at 11:09:04AM +0900, Warren Togami wrote: > Jeff Spaleta wrote: > >On 2/5/06, Thorsten Leemhuis wrote: > >>This is far from perfect solution. Easy example: > > > >The PERFECT solution.. is to integrate update notifications back into > >available client tools.. so noone has to dink around with any > >mailinglist at all to see update annoucements. In the perfect world, > >all you have to do is ask your client tool to give you a summary of > >relevant notifications for each repo you are interested in from the > >repo metadata. > > I strongly agree that users shouldn't need to fumble through mail in > order to read update announcements. This should be part of our package > metadata and easily browsable using package management tools. This has been in the works for quite some time now, and is nearing completion. The current implementation[0] we've been discussing is to have a central metadata server which will be [optionally] queried by createrepo to acquire the update metadata. More details can be found on the yum-devel thread[1]. luke [0]: http://people.redhat.com/lmacken/metadata/ [1]: https://lists.dulug.duke.edu/pipermail/yum-devel/2006-January/001840.html From mharris at mharris.ca Mon Feb 6 03:43:37 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Sun, 05 Feb 2006 22:43:37 -0500 Subject: Xorg 6.9 Update for FC4? In-Reply-To: <25327.194.94.224.254.1139130574.squirrel@arlette.freesurf.fr> References: <43E508B9.80702@gmx.net> <25327.194.94.224.254.1139130574.squirrel@arlette.freesurf.fr> Message-ID: <43E6C5E9.1070406@mharris.ca> Joachim Frieben wrote: > No need to bother Mike: as I pointed out in my previuos comment, Xorg 6.9 > packages for FC4 have already been created by various guys. The S/RPMS are > freely available on the net. For instance, check: > > http://washington.kelkoo.net/epia/FC4 > > They were particularly built having the S3 Unichrome chip in mind but of > course they will also work on other hardware. Yeah, I know there are 3rd party rpm packages. I mentioned that in a previous email. ;o) I also mentioned that the 3rd party RPMs of 6.9 that I saw before, were not just 6.9, but 6.9 plus random extra stuff patched in. Things that would not be present in Red Hat packages. As stated previously, I suggested that people could use those if desired. Having said that, I haven't looked at the rpms at the above URL, so they could be quite different from the ones I had previously looked at. As always, caveat emptor. If I do create a set of 6.9 rpms, they'll be done in standard Red Hat fashion. No experimental doodads, etc. ;) -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From louisg00 at bellsouth.net Mon Feb 6 03:44:18 2006 From: louisg00 at bellsouth.net (Louis E Garcia II) Date: Sun, 05 Feb 2006 22:44:18 -0500 Subject: bad dependency with sound juicer Message-ID: <1139197458.4560.8.camel@soncomputer> when the dependency on gstreamer went from 0.8 to 0.10 the new requires should have been gstreamer-plugins-base not gstreamer-plugins. -Louis From 777tahder at schlaegel.com Mon Feb 6 03:56:56 2006 From: 777tahder at schlaegel.com (Schlaegel) Date: Sun, 5 Feb 2006 19:56:56 -0800 Subject: Xorg 6.9 Update for FC4? In-Reply-To: <43E47C9B.8040806@mharris.ca> References: <1139023771.3267.8.camel@tuxhugger> <43E47C9B.8040806@mharris.ca> Message-ID: <4e1f5c1a0602051956y9593279t1719731ea1db3920@mail.gmail.com> On 2/4/06, Mike A. Harris wrote: > A 6.9 release would be a lot more work than that, but much much > less work than doing a 7.0 release. I already have 6.9 beta rpms > which I could probably update cleanly to 6.9 in a day or two, ... > If there is strong enough interest in 6.9 rpms, I might be able to > be convinced to spend some of my personal time updating my previous > 6.8.99.x packages on the weekend sometime. Of course it has to be > a pleasant experience for me to expend the effort though. The last > time I did it, the feedback I got from people was mostly inflammatory > and negative, with no appreciation for the effort, so I stopped doing > it. For an example of what I mean by this, simply look back a few > messages in this list to discover how rude and thankless people can > sometimes be. I am very interested in 6.9 rpms for FC4 (I need multihead, independent, and concurrent X servers). I tried to rpmbuild my own using the kit at http://sergiomb.no-ip.org/xorg/ which is based upon your previous 6.8.99.x packages, but could not get a working package. I considered trying to get it to work myself, but the spec file is more complex than any spec file I have ever seen. So, I for one would be very appreciative of any time you spent on the issue. Hurray for Mike Harris! -Schlaegel From t.matsuu at gmail.com Mon Feb 6 04:00:01 2006 From: t.matsuu at gmail.com (MATSUURA Takanori) Date: Mon, 6 Feb 2006 13:00:01 +0900 Subject: FC5 and firefox-trunk Message-ID: <6f27515e0602052000ia441c5es@mail.gmail.com> Dear all, Do you have any good idea? Now I'm trying to build trunk version of firefox and there is a problem. https://bugzilla.mozilla.org/show_bug.cgi?id=325716 https://bugzilla.mozilla.org/show_bug.cgi?id=325719 FC5 has cairo-1.0.2 and firefox-trunk has 1.1 from cairo-CVS. 1. If we run configure script with '--enable-system-cairo', firefox cannot build because firefox-trunk source calls cairo-1.1-specific functions. 2. If we run configure script with '--disable-system-cairo', firefox cannot build because system cairo is detected by 'pkg-config gtk+-2.0'. MATSUURA Takanori From lmacken at redhat.com Mon Feb 6 04:22:38 2006 From: lmacken at redhat.com (Luke Macken) Date: Sun, 5 Feb 2006 23:22:38 -0500 Subject: bad dependency with sound juicer In-Reply-To: <1139197458.4560.8.camel@soncomputer> References: <1139197458.4560.8.camel@soncomputer> Message-ID: <20060206042238.GA25587@tomservo.boston.redhat.com> On Sun, Feb 05, 2006 at 10:44:18PM -0500, Louis E Garcia II wrote: > when the dependency on gstreamer went from 0.8 to 0.10 the new requires > should have been gstreamer-plugins-base not gstreamer-plugins. > > -Louis https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179826 From 777tahder at schlaegel.com Mon Feb 6 04:32:50 2006 From: 777tahder at schlaegel.com (Schlaegel) Date: Sun, 5 Feb 2006 20:32:50 -0800 Subject: Xorg 6.9 Update for FC4? In-Reply-To: <25327.194.94.224.254.1139130574.squirrel@arlette.freesurf.fr> References: <43E508B9.80702@gmx.net> <25327.194.94.224.254.1139130574.squirrel@arlette.freesurf.fr> Message-ID: <4e1f5c1a0602052032n4b97805du97c436a5f6952e66@mail.gmail.com> On 2/5/06, Joachim Frieben wrote: > No need to bother Mike: as I pointed out in my previuos comment, Xorg 6.9 > packages for FC4 have already been created by various guys. The S/RPMS are > freely available on the net. For instance, check: > http://washington.kelkoo.net/epia/FC4 I tried to install those packages today via yum, but it seems that their xorg-x11-Xnest and xorg-x11-devel packages need xorg-x11 and xorg-x11-libs packages with a version at or higher than 6.9.0-1, while the site only offers 6.9.0. Perhaps the site is in the middle of an update. My yum error: > xorg-x11-6.9-0.FC4.ucr.5. 100% |=========================| 173 kB 00:24 > ---> Package xorg-x11.i386 0:6.9-0.FC4.ucr.5 set to be updated [snip] > Error: Missing Dependency: xorg-x11 = 6.9.0-1 is needed by package xorg-x11-Xnest > Error: Missing Dependency: xorg-x11-libs = 6.9.0-1 is needed by package xorg-x11-devel So for me, I would still love the expertise of Mike involved with even an informal package. From fherrera at gmail.com Mon Feb 6 05:58:46 2006 From: fherrera at gmail.com (Fernando Herrera) Date: Mon, 6 Feb 2006 06:58:46 +0100 Subject: XGL In-Reply-To: References: <43E15BEF.3070405@mharris.ca> Message-ID: <58d389c20602052158k7830e344v3598723df964cda8@mail.gmail.com> On 2/4/06, Benjy Grogan wrote: > Alright. Thanks for the info. I'm looking forward to some of these future > X technologies. Is there a good source of information somewhere about the > architecture of X11 R7.0? As well as some of these technologies being > developed by RedHat and Sun? At the moment I'm only aware of Novell's work > on X. Don't miss XDevConf 2006 starting on Wed. Some highlights: - "Xgl" - David Reveman, Novell - "Avalon" - Matthias Hopf - "Status Update on Project Looking Glass" - Deron Johnson, Sun - "Development Challenges for X and GL" - Kevin Martin, Red Hat - "Accelerated Indirect GLX" - Kristian H?gsberg, Red Hat - "A preview of the GNOME compositing manager" - S?ren Sandmann Pedersen, Red Hat Promising, isn't it? I hope we can get it webcasted as past years. Salu2 From fedora at leemhuis.info Mon Feb 6 06:30:19 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 06 Feb 2006 07:30:19 +0100 Subject: Proposed and major updates policy In-Reply-To: <43E6AFC0.3010308@redhat.com> References: <43E4AC9E.2050907@fedoraproject.org> <200602041304.19683.lamont@gurulabs.com> <43E50A71.9060905@mharris.ca> <200602041319.03294.lamont@gurulabs.com> <43E62607.9070807@fedoraproject.org> <1139158188.2948.30.camel@localhost.localdomain> <604aa7910602051755y1ac6e85uaa9164f33b26fe5f@mail.gmail.com> <43E6AFC0.3010308@redhat.com> Message-ID: <1139207419.3057.7.camel@thl.ct.heise.de> Am Montag, den 06.02.2006, 11:09 +0900 schrieb Warren Togami: > Jeff Spaleta wrote: > > On 2/5/06, Thorsten Leemhuis wrote: > >> This is far from perfect solution. Easy example: > > > > The PERFECT solution.. is to integrate update notifications back into > > available client tools.. so noone has to dink around with any > > mailinglist at all to see update annoucements. In the perfect world, > > all you have to do is ask your client tool to give you a summary of > > relevant notifications for each repo you are interested in from the > > repo metadata. > > I strongly agree that users shouldn't need to fumble through mail in > order to read update announcements. Strongly agreed. > This should be part of our package > metadata and easily browsable using package management tools. But it seems there are people (like me) that want to discuss on a mailinglist if the problems they see with packages from updates-testing are individual to their computers or a general problem. They try to avoid filing stupid bugs or duplicates. And it seems some of these people don't want to do that on fedora-test-list because they feel lost in with all the rawhide traffic there. CU Thorsten 'I always hear that nobody uses updates testing -- this might be one of the reasons' Leemhuis From che666 at gmail.com Mon Feb 6 08:58:29 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Mon, 6 Feb 2006 09:58:29 +0100 Subject: XGL In-Reply-To: <58d389c20602052158k7830e344v3598723df964cda8@mail.gmail.com> References: <43E15BEF.3070405@mharris.ca> <58d389c20602052158k7830e344v3598723df964cda8@mail.gmail.com> Message-ID: 2006/2/6, Fernando Herrera : > On 2/4/06, Benjy Grogan wrote: > > Alright. Thanks for the info. I'm looking forward to some of these future > > X technologies. Is there a good source of information somewhere about the > > architecture of X11 R7.0? As well as some of these technologies being > > developed by RedHat and Sun? At the moment I'm only aware of Novell's work > > on X. > > Don't miss XDevConf 2006 starting on Wed. Some highlights: > - "Xgl" - David Reveman, Novell > - "Avalon" - Matthias Hopf > - "Status Update on Project Looking Glass" - Deron Johnson, Sun > - "Development Challenges for X and GL" - Kevin Martin, Red Hat > - "Accelerated Indirect GLX" - Kristian H?gsberg, Red Hat > - "A preview of the GNOME compositing manager" - S?ren Sandmann > Pedersen, Red Hat > > Promising, isn't it? I hope we can get it webcasted as past years. > > Salu2 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > very interesting indeed ;) i guess lots of users cant wait to get the latest eye candy tech news ;)) regards, Rudolf Kastl From naoki at valuecommerce.com Mon Feb 6 09:00:06 2006 From: naoki at valuecommerce.com (Naoki) Date: Mon, 06 Feb 2006 18:00:06 +0900 Subject: fc5 test2 haldaemon failed? In-Reply-To: <43E610EB.1080001@argo.co.il> References: <43E5FEF9.20504@valuecommerce.com> <43E610EB.1080001@argo.co.il> Message-ID: <43E71016.3060700@valuecommerce.com> Avi Kivity wrote: >> > try running hald with --verbose > Nada. # /bin/bash -c 'ulimit -S -c 0 >/dev/null 2>&1 ; hald --retain-privileges --verbose=yes' 17:55:47.525 [I] hald.c:515: hal 0.5.6 17:55:47.525 [I] hald.c:524: Will daemonize 17:55:47.525 [I] hald.c:525: Becoming a daemon # ps -ef|grep hal Nothing... From buildsys at redhat.com Mon Feb 6 09:01:54 2006 From: buildsys at redhat.com (Build System) Date: Mon, 6 Feb 2006 04:01:54 -0500 Subject: rawhide report: 20060206 changes Message-ID: <200602060901.k1691s53024943@porkchop.devel.redhat.com> Updated Packages: NetworkManager-0.5.1-10.cvs20060205 ----------------------------------- * Sun Feb 05 2006 Dan Williams 0.5.1-10.cvs20060205 - Workarounds for madwifi/Atheros cards - Do better with non-SSID-broadcasting access points - Fix hangs when access points change settings * Thu Feb 02 2006 Dan Williams 0.5.1-9.cvs20060202 - Own /var/run/NetworkManager, fix SELinux issues bash-3.1-6 ---------- * Sun Feb 05 2006 Tim Waugh 3.1-6 - Patchlevel 7. * Wed Jan 18 2006 Tim Waugh - Removed inaccuracies from %description (bug #178189). epiphany-1.9.6-2 ---------------- * Sun Feb 05 2006 Matthias Clasen 1.9.6-2 - Update requires file-4.16-6 ----------- * Sat Feb 04 2006 Radek Vok??l 4.16-6 - xen patch, recognizes Xen saved domain * Fri Jan 13 2006 Radek Vokal 4.16-5 - fix for 64bit arrays * Fri Dec 09 2005 Jesse Keating - rebuilt kdenetwork-7:3.5.1-1 -------------------- * Sun Feb 05 2006 Than Ngo 7:3.5.1-1 - 3.5.1 kdesdk-3.5.1-1 -------------- * Sun Feb 05 2006 Than Ngo 3.5.1-1 - 3.5.1 kdeutils-6:3.5.1-1 ------------------ * Sun Feb 05 2006 Than Ngo 6:3.5.1-1 - 3.5.1 kdevelop-9:3.3.1-1 ------------------ * Sun Feb 05 2006 Than Ngo 9:3.3.1-1 - 3.3.1 kdewebdev-6:3.5.1-1 ------------------- * Sun Feb 05 2006 Than Ngo 6:3.5.1-1 - 3.5.1 mozilla-37:1.7.12-4 ------------------- * Sun Feb 05 2006 Christopher Aillon 37:1.7.12-4 - Fix CVE-2005-4134, CVE-2006-0292, CVE-2006-0296 openoffice.org-1:2.0.1.1-10.2 ----------------------------- * Thu Feb 02 2006 Caolan McNamara - 1:2.0.1.1-10 - reshuffle bridge patch - reimplement lang from locale patch redhat-artwork-0.237-1 ---------------------- * Sun Feb 05 2006 Matthias Clasen 0.237-1 - Fix Bluecurve-inverse wait cursor ruby-1.8.4-3 ------------ * Mon Feb 06 2006 Akira TAGOH - 1.8.4-3 - ruby-1.8.4-no-eaccess.patch: backported from ruby CVS to avoid conflict between newer glibc. (#179835) sound-juicer-2.13.4-3 --------------------- * Sun Feb 05 2006 Christopher Aillon 2.13.4-3 - Fix broken Requires wpa_supplicant-0.5.1-1 ---------------------- * Sun Feb 05 2006 Dan Williams 0.5.1-1 - Update to 0.5.1 - Add WE auth fallback to actually work with older drivers xorg-x11-drv-ati-6.5.7.3-3 -------------------------- * Sun Feb 05 2006 Mike A. Harris 6.5.7.3-3 - Updated radeon.xinf to be up to date with the xf86PciInfo.h from the Xorg X server 1.0.1-1 source. This should account for all supported Radeon models now modulo errors/omissions. Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- ccs-devel - 1.0.2-3.1.ppc requires ccs = 0:1.0.2-3.1 gulm - 1.0.4-2.FC5.1.ppc requires ccs Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.4-2.s390 requires kernel >= 0:2.6.9-11 Broken deps for s390x ---------------------------------------------------------- libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) systemtap - 0.5.4-2.s390x requires kernel >= 0:2.6.9-11 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 From caillon at redhat.com Mon Feb 6 09:35:42 2006 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 06 Feb 2006 04:35:42 -0500 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <43E6763A.8050509@uindy.edu> References: <1139006387.2652.29.camel@bree.local.net> <1139014200.2863.65.camel@yoda.loki.me> <43E48DDD.4060508@vip.hr> <200602041255.23869.lamont@gurulabs.com> <43E5095E.3060804@mharris.ca> <43E6763A.8050509@uindy.edu> Message-ID: <43E7186E.7050307@redhat.com> On 02/05/2006 05:03 PM, D Canfield wrote: > In fact, the only two things I'm eager for in FC5 are a > working suspend on my thinkpad, and evolution syncing on my Treo > (neither of which looks is looking too promising anymore). Suspend should be working for FC5, especially on thinkpads. Works great on my T41 at least. From gnomeuser at gmail.com Mon Feb 6 09:35:43 2006 From: gnomeuser at gmail.com (David Nielsen) Date: Mon, 06 Feb 2006 10:35:43 +0100 Subject: XGL In-Reply-To: <58d389c20602052158k7830e344v3598723df964cda8@mail.gmail.com> References: <43E15BEF.3070405@mharris.ca> <58d389c20602052158k7830e344v3598723df964cda8@mail.gmail.com> Message-ID: <1139218543.9515.6.camel@price.stavtrup-st.dk> man, 06 02 2006 kl. 06:58 +0100, skrev Fernando Herrera: > On 2/4/06, Benjy Grogan wrote: > > Alright. Thanks for the info. I'm looking forward to some of these future > > X technologies. Is there a good source of information somewhere about the > > architecture of X11 R7.0? As well as some of these technologies being > > developed by RedHat and Sun? At the moment I'm only aware of Novell's work > > on X. > > Don't miss XDevConf 2006 starting on Wed. Some highlights: > - "Xgl" - David Reveman, Novell > - "Avalon" - Matthias Hopf > - "Status Update on Project Looking Glass" - Deron Johnson, Sun > - "Development Challenges for X and GL" - Kevin Martin, Red Hat > - "Accelerated Indirect GLX" - Kristian H?gsberg, Red Hat > - "A preview of the GNOME compositing manager" - S?ren Sandmann > Pedersen, Red Hat Does anyone know if there will be streams or captured videos of the XDevConf talks? - David -- Obligatory shameless blog plug - the GNOME commentary located at: www.lovesunix.net/blog From gnomeuser at gmail.com Mon Feb 6 09:38:05 2006 From: gnomeuser at gmail.com (David Nielsen) Date: Mon, 06 Feb 2006 10:38:05 +0100 Subject: XGL In-Reply-To: <1139218543.9515.6.camel@price.stavtrup-st.dk> References: <43E15BEF.3070405@mharris.ca> <58d389c20602052158k7830e344v3598723df964cda8@mail.gmail.com> <1139218543.9515.6.camel@price.stavtrup-st.dk> Message-ID: <1139218686.9515.8.camel@price.stavtrup-st.dk> man, 06 02 2006 kl. 10:35 +0100, skrev David Nielsen: > Does anyone know if there will be streams or captured videos of the > XDevConf talks? Answering myself: http://freedesktop.org/wiki/Software/XDevConf/Cambridge2005 -- Obligatory shameless blog plug - the GNOME commentary located at: www.lovesunix.net/blog From tla-ml at rasmil.dk Mon Feb 6 16:37:50 2006 From: tla-ml at rasmil.dk (Tim Lauridsen) Date: Mon, 06 Feb 2006 11:37:50 -0500 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <43E7186E.7050307@redhat.com> References: <1139006387.2652.29.camel@bree.local.net> <1139014200.2863.65.camel@yoda.loki.me> <43E48DDD.4060508@vip.hr> <200602041255.23869.lamont@gurulabs.com> <43E5095E.3060804@mharris.ca> <43E6763A.8050509@uindy.edu> <43E7186E.7050307@redhat.com> Message-ID: <43E77B5E.8090804@rasmil.dk> Christopher Aillon wrote: > On 02/05/2006 05:03 PM, D Canfield wrote: >> In fact, the only two things I'm eager for in FC5 are a working >> suspend on my thinkpad, and evolution syncing on my Treo (neither of >> which looks is looking too promising anymore). > > Suspend should be working for FC5, especially on thinkpads. Works > great on my T41 at least. > On my T30 suspend is working, but it can't wakeup again :-((. Tim From link at pobox.com Mon Feb 6 11:00:44 2006 From: link at pobox.com (Terje Bless) Date: Mon, 6 Feb 2006 12:00:44 +0100 Subject: e1000 in rawhide kernel In-Reply-To: <5256d0b0602030116l2f1415daofaa13ab36f7d22f3@mail.gmail.com> Message-ID: Peter Robinson wrote: >The higher end ones take ages to negotiate because they try and neg >Spanning Tree Protocol first so the port goes through a blocking, >discovery and then is finally into the forwarding stage. ?Higher end? switches (such as el cheapo Dells) can take up to 50 seconds to start forwarding data while the Spanning Tree Protocol runs through its BLOCKING, LISTENING, LEARNING, FORWARDING states; but that is assuming you are, for some reason, running STP on an Access port. Normally you'll have configured these with the equivalent of (Cisco) IOS' "spanning-tree portfast" to shortcut directly from BLOCKING to FORWARDING. Semi-recent IOS can also do this for trunk ports if you need to pass tagged VLANs out to your server for some reason. IOW, switches that take ages to start passing traffic on Access ports ? where all relevant FC boxen will live ? are either mis-configured or broken. -- ?Oh, my. What? Did I hurt your little, iddy, biddy feelings widdle MCSE kind of person?? -- Tina Holmboe From pbrobinson at gmail.com Mon Feb 6 11:04:23 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 6 Feb 2006 11:04:23 +0000 Subject: e1000 in rawhide kernel In-Reply-To: References: <5256d0b0602030116l2f1415daofaa13ab36f7d22f3@mail.gmail.com> Message-ID: <5256d0b0602060304h3f8fef02u2fc42eaf3d0d7708@mail.gmail.com> > Peter Robinson wrote: > > >The higher end ones take ages to negotiate because they try and neg > >Spanning Tree Protocol first so the port goes through a blocking, > >discovery and then is finally into the forwarding stage. > > "Higher end" switches (such as el cheapo Dells) can take up to 50 seconds to > start forwarding data while the Spanning Tree Protocol runs through its > BLOCKING, LISTENING, LEARNING, FORWARDING states; but that is assuming you are, > for some reason, running STP on an Access port. > > Normally you'll have configured these with the equivalent of (Cisco) IOS' > "spanning-tree portfast" to shortcut directly from BLOCKING to FORWARDING. > Semi-recent IOS can also do this for trunk ports if you need to pass tagged > VLANs out to your server for some reason. > > IOW, switches that take ages to start passing traffic on Access ports ? where > all relevant FC boxen will live ? are either mis-configured or broken. Or not configured. The number of sites that I've been to that have switches that run the default config is amazing and its a question that needs to be asked. Pete From kloczek at zie.pg.gda.pl Mon Feb 6 11:06:45 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=) Date: Mon, 06 Feb 2006 12:06:45 +0100 Subject: gcc 64-bit mode disapear on x86_64 Message-ID: <1139224005.4322.21.camel@kloczek01.pracownicy.zie> [kloczek at kloczek01 src]$ LANG= make CC="gcc -m64" passwd if gcc -m64 -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -I../libmisc -DLOCALEDIR=\"/usr/share/locale\" -g -O2 -MT passwd.o -MD -MP -MF ".deps/passwd.Tpo" -c -o passwd.o passwd.c; \ then mv -f ".deps/passwd.Tpo" ".deps/passwd.Po"; else rm -f ".deps/passwd.Tpo"; exit 1; fi passwd.c:1: sorry, unimplemented: 64-bit mode not compiled in make: *** [passwd.o] Error 1 [kloczek at kloczek01 src]$ rpm -q gcc --qf "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n" gcc-4.1.0-0.20.x86_64 [kloczek at kloczek01 src]$ gcc -dumpspecs | grep 64 [kloczek at kloczek01 src]$ kloczek From jakub at redhat.com Mon Feb 6 11:12:23 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 6 Feb 2006 06:12:23 -0500 Subject: gcc 64-bit mode disapear on x86_64 In-Reply-To: <1139224005.4322.21.camel@kloczek01.pracownicy.zie> References: <1139224005.4322.21.camel@kloczek01.pracownicy.zie> Message-ID: <20060206111223.GC24295@devserv.devel.redhat.com> On Mon, Feb 06, 2006 at 12:06:45PM +0100, Tomasz K?oczko wrote: > > [kloczek at kloczek01 src]$ LANG= make CC="gcc -m64" passwd > if gcc -m64 -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -I../libmisc > -DLOCALEDIR=\"/usr/share/locale\" -g -O2 -MT passwd.o -MD -MP -MF > ".deps/passwd.Tpo" -c -o passwd.o passwd.c; \ > then mv -f ".deps/passwd.Tpo" ".deps/passwd.Po"; else rm -f > ".deps/passwd.Tpo"; exit 1; fi > passwd.c:1: sorry, unimplemented: 64-bit mode not compiled in > make: *** [passwd.o] Error 1 > > [kloczek at kloczek01 src]$ rpm -q gcc --qf > "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n" > gcc-4.1.0-0.20.x86_64 What arch is cpp: rpm -q cpp --qf '%{name}-%{version}-%{release}.%{arch}\n' ? Should be x86_64 too. Jakub From hughsient at gmail.com Mon Feb 6 11:11:39 2006 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 06 Feb 2006 11:11:39 +0000 Subject: fc5 test2 haldaemon failed? In-Reply-To: <43E71016.3060700@valuecommerce.com> References: <43E5FEF9.20504@valuecommerce.com> <43E610EB.1080001@argo.co.il> <43E71016.3060700@valuecommerce.com> Message-ID: <1139224299.3503.0.camel@localhost.localdomain> On Mon, 2006-02-06 at 18:00 +0900, Naoki wrote: > Avi Kivity wrote: > >> > > try running hald with --verbose > > > Nada. > # /bin/bash -c 'ulimit -S -c 0 >/dev/null 2>&1 ; hald > --retain-privileges --verbose=yes' > 17:55:47.525 [I] hald.c:515: hal 0.5.6 > 17:55:47.525 [I] hald.c:524: Will daemonize > 17:55:47.525 [I] hald.c:525: Becoming a daemon > # ps -ef|grep hal You want to add --daemon=no to the command line: hald --retain-privileges --verbose=yes --daemon=no Richard. From kloczek at zie.pg.gda.pl Mon Feb 6 11:24:53 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=) Date: Mon, 06 Feb 2006 12:24:53 +0100 Subject: gcc 64-bit mode disapear on x86_64 In-Reply-To: <20060206111223.GC24295@devserv.devel.redhat.com> References: <1139224005.4322.21.camel@kloczek01.pracownicy.zie> <20060206111223.GC24295@devserv.devel.redhat.com> Message-ID: <1139225093.19883.5.camel@kloczek01.pracownicy.zie> Dnia 06-02-2006, pon o godzinie 06:12 -0500, Jakub Jelinek napisa?(a): [..] > > [kloczek at kloczek01 src]$ rpm -q gcc --qf > > "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n" > > gcc-4.1.0-0.20.x86_64 > > What arch is cpp: > rpm -q cpp --qf '%{name}-%{version}-%{release}.%{arch}\n' > ? Should be x86_64 too. Yes it is. $ rpm -q cpp --qf "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n" cpp-4.1.0-0.20.x86_64 On this system I have installed only x86_64 packages. $ rpm -qa --qf "%{ARCH}\n" | sort | uniq -c 208 noarch 1306 x86_64 kloczek From naoki at valuecommerce.com Mon Feb 6 13:01:51 2006 From: naoki at valuecommerce.com (Naoki) Date: Mon, 06 Feb 2006 22:01:51 +0900 Subject: fc5 test2 haldaemon failed? In-Reply-To: <1139224299.3503.0.camel@localhost.localdomain> References: <43E5FEF9.20504@valuecommerce.com> <43E610EB.1080001@argo.co.il> <43E71016.3060700@valuecommerce.com> <1139224299.3503.0.camel@localhost.localdomain> Message-ID: <43E748BF.5050701@valuecommerce.com> Richard Hughes wrote: > > You want to add --daemon=no to the command line: > > hald --retain-privileges --verbose=yes --daemon=no > > Richard. > > Cheers, last few lines were : 22:00:45.443 [I] hald.c:659: Device probing completed 22:00:45.443 [I] hald_dbus.c:3091: entering 22:00:45.444 [E] hald_dbus.c:3098: dbus_bus_get(): Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory 22:00:45.444 [I] util.c:1268: Killing helper with pid 4663 22:00:45.444 [I] util.c:1268: Killing helper with pid 4659 22:00:45.444 [I] util.c:1268: Killing helper with pid 4644 From canfield at uindy.edu Mon Feb 6 14:37:42 2006 From: canfield at uindy.edu (D Canfield) Date: Mon, 06 Feb 2006 09:37:42 -0500 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <43E77B5E.8090804@rasmil.dk> References: <1139006387.2652.29.camel@bree.local.net> <1139014200.2863.65.camel@yoda.loki.me> <43E48DDD.4060508@vip.hr> <200602041255.23869.lamont@gurulabs.com> <43E5095E.3060804@mharris.ca> <43E6763A.8050509@uindy.edu> <43E7186E.7050307@redhat.com> <43E77B5E.8090804@rasmil.dk> Message-ID: <43E75F36.1020507@uindy.edu> Tim Lauridsen wrote: > Christopher Aillon wrote: > >> On 02/05/2006 05:03 PM, D Canfield wrote: >> >>> In fact, the only two things I'm eager for in FC5 are a working >>> suspend on my thinkpad, and evolution syncing on my Treo (neither of >>> which looks is looking too promising anymore). >> >> >> Suspend should be working for FC5, especially on thinkpads. Works >> great on my T41 at least. >> > On my T30 suspend is working, but it can't wakeup again :-((. > > Tim > That's my problem as well. The SATA-HD resume finally seems to be working, but if I suspend/resume from a text console, I get no video whatsoever (not even a backlight), and if I suspend/resume in X, I get a corrupted screen. The system clearly resumes though, as I can blind-type to login and do an ls -lR / to make my hard drive flash and such. My T43 has an ATI X300 chipset, I believe, if that provides any insight to anyone. DC From clydekunkel7734 at cox.net Mon Feb 6 15:10:26 2006 From: clydekunkel7734 at cox.net (Clyde E. Kunkel) Date: Mon, 06 Feb 2006 10:10:26 -0500 Subject: Request for testers: Video hardware autodetection In-Reply-To: <43E4A50E.5070209@mharris.ca> References: <43E4A50E.5070209@mharris.ca> Message-ID: <43E766E2.8070908@cox.net> Mike A. Harris wrote: > The latest xorg-x11-drv-* driver packages contain videoaliases > files for kudzu et al. to use for video card autodetection and > driver mapping. > > If you have a video card which is assigned the "vesa" driver > from the above test, then it is either not supported by the > drivers, or we're missing a PCI ID to driver mapping for that > card/chip. To determine if it is supported by the driver, > hand edit the xorg.conf and replace the vesa driver with the > native X driver for the particular vendor. ie: "nv" for > Nvidia, "ati" for ATI, etc., and test to see if X starts up. > 2/6/06 rawhide ati driver xorg-x11-drv-ati-6.5.7.3-3 still detects radeon 9200 AGP as vesa. BZ 180001 updated. -- Regards, Old Fart (my reply-to address is "munged" to defeat spambots) From vd at paradigma.pt Mon Feb 6 14:24:41 2006 From: vd at paradigma.pt (Vitor Domingos) Date: Mon, 6 Feb 2006 14:24:41 +0000 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: 43E77B5E.8090804@rasmil.dk Message-ID: I'm having the same problem with suspend2ram, in which the problem resides on the radeon card. It neves shows me the X. We should have on team only working/reporting bugs on laptops, just like the one ubuntu has. //VD On Mon, 06 Feb 2006 11:37:50 -0500, Tim Lauridsen wrote: > Christopher Aillon wrote: >> On 02/05/2006 05:03 PM, D Canfield wrote: >>> In fact, the only two things I'm eager for in FC5 are a working >>> suspend on my thinkpad, and evolution syncing on my Treo (neither of >>> which looks is looking too promising anymore). >> >> Suspend should be working for FC5, especially on thinkpads. Works >> great on my T41 at least. >> > On my T30 suspend is working, but it can't wakeup again :-((. > > Tim > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From sundaram at fedoraproject.org Mon Feb 6 15:30:39 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 06 Feb 2006 21:00:39 +0530 Subject: Proposed and major updates policy In-Reply-To: <43E6A6EF.4020008@redhat.com> References: <43E4AC9E.2050907@fedoraproject.org> <1139070457.7617.13.camel@gilboa-home-dev.localhost> <43E6A6EF.4020008@redhat.com> Message-ID: <43E76B9F.1040805@fedoraproject.org> Warren Togami wrote: > Gilboa Davara wrote: > >> I second that. >> The lack of FC package update policy is a real pain in the back side. >> The KDE 3.5.x release backlash was just an example of why such a policy >> must be set. >> > > IMHO, the vast majority of updates have been no problem. KDE however > has been a bit problematic in particular. Upgrading such a large > group of packages is reckless especially when done without testing. > Unfortunately, I am afraid some developers do not test new updates > before pushing. If a clear policy is in place there would be more accountability. Without this, the decision to push updates directly is entirely in the hands of the relevant package maintainers who might just skip the testing repository even when it is generally required. > > I believe we don't need any strict policy like "a week in testing" > repository because the majority of updates are really no problem. We > should however say "test it and be sure it works, and if you are less > sure put it in testing". Also bigger updates like an entire new KDE > release definitely must go into testing. > > Requiring ALL updates to go into the testing repository will > unnecessary slow down progress. I didnt claim that all updates need to be pushed to the testing repository however if there are exceptions then the rationale behind those exceptions should be better communicated and in case of general guidelines, better documented. Security fixes for might directly go into updates repository while major revisions of packages should go through updates-testing repository is a simple enough policy to enforce for example. I dont for a moment believe that all potential issues or regressions in updates would be caught in the updates-testing repository however there is a potential to have less issues when the testing repository is used by testers who might provide better feedback. The problem is not necessarily what we do but a communication gap in why we do it , the way we do it. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From alan at redhat.com Mon Feb 6 15:30:40 2006 From: alan at redhat.com (Alan Cox) Date: Mon, 6 Feb 2006 10:30:40 -0500 Subject: Question about IT821x driver and DMA In-Reply-To: <20060205110631.GA6013@wolves.durham.nc.us> References: <20060205110631.GA6013@wolves.durham.nc.us> Message-ID: <20060206153040.GA21809@devserv.devel.redhat.com> On Sun, Feb 05, 2006 at 06:06:31AM -0500, G.Wolfe Woodbury wrote: > It seems that I cannot set DMA with hdparm on this drive without driving > the system into a lockup. I'd strongly suggest flashing the ATAPI/IDE firmware to the device not the RAID firmware (or setting the BIOS option, or kernel boot option) if you are having these kind of problems. The IT8212 smart firmware seems to be somewhat touchy. From alan at redhat.com Mon Feb 6 15:37:30 2006 From: alan at redhat.com (Alan Cox) Date: Mon, 6 Feb 2006 10:37:30 -0500 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <200602041157.17339.prigault@oricom.ca> References: <200602041157.17339.prigault@oricom.ca> Message-ID: <20060206153730.GA24791@devserv.devel.redhat.com> On Sat, Feb 04, 2006 at 11:57:16AM -0500, Philippe Rigault wrote: > relevance of March 15 as the release date for FC5-final, which I see a the > worst possible choice in March, given the following release dates: > March 15 GNOME-2.14, koffice-1.5 > March 17 KDE-3.5.2 > > These would make Fecora Core 5 labeled as both "obsolete" and "unstable" if it It would need to be a large delay because moving to major new versions means invalidating a lot of the testing work in T1/T2. If sliding test2 a bit to fit these would have worked then maybe there would be a practical way to do it, but test3 > final is about polishing critical final bugs. Alan -- "He's been overclocked. All that beer you see him drinking ? - Coolant." - Adam Thornton From i.pilcher at comcast.net Mon Feb 6 16:17:27 2006 From: i.pilcher at comcast.net (Ian Pilcher) Date: Mon, 06 Feb 2006 10:17:27 -0600 Subject: Proposed and major updates policy In-Reply-To: <43E76B9F.1040805@fedoraproject.org> References: <43E4AC9E.2050907@fedoraproject.org> <1139070457.7617.13.camel@gilboa-home-dev.localhost> <43E6A6EF.4020008@redhat.com> <43E76B9F.1040805@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > I didnt claim that all updates need to be pushed to the testing > repository however if there are exceptions then the rationale behind > those exceptions should be better communicated and in case of general > guidelines, better documented. Security fixes for might directly go > into updates repository while major revisions of packages should go > through updates-testing repository is a simple enough policy to enforce > for example. I dont for a moment believe that all potential issues or > regressions in updates would be caught in the updates-testing repository > however there is a potential to have less issues when the testing > repository is used by testers who might provide better feedback. The > problem is not necessarily what we do but a communication gap in why we > do it , the way we do it. At the very least, it provides a nice comeback when people complain that update X broke feature Y for them. -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From jkeating at j2solutions.net Mon Feb 6 16:34:43 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 06 Feb 2006 08:34:43 -0800 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <43E7186E.7050307@redhat.com> References: <1139006387.2652.29.camel@bree.local.net> <1139014200.2863.65.camel@yoda.loki.me> <43E48DDD.4060508@vip.hr> <200602041255.23869.lamont@gurulabs.com> <43E5095E.3060804@mharris.ca> <43E6763A.8050509@uindy.edu> <43E7186E.7050307@redhat.com> Message-ID: <1139243683.3188.14.camel@yoda.loki.me> On Mon, 2006-02-06 at 04:35 -0500, Christopher Aillon wrote: > Suspend should be working for FC5, especially on thinkpads. Works great > on my T41 at least. > Suspend on T42 yes. Resume? Kind of. I resume it goes RIGHT back to sleep, so I have to fiddle w/ the lid button once to get it to wake back up again. Hibernate? Not so much. Never fully goes into hibernate, just pops back out. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-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 Mon Feb 6 17:03:43 2006 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 6 Feb 2006 09:03:43 -0800 (PST) Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <1139006387.2652.29.camel@bree.local.net> Message-ID: <20060206170343.96873.qmail@web51514.mail.yahoo.com> >There is an ABI change in the gcc/glibc stack that requires a rebuild of the >entire distribution. Out of curiosity, when the rebuild occurs...does the script use an alphabetical listing of the packages from a to z. Or does the script try to build the packages in a somewhat ordered fashion from no dependencies (attr, zlib, bzip, etc) to more complicated packages that have many dependencies (mkinitrd, pam, slang, etc.) -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From jkeating at redhat.com Mon Feb 6 17:12:51 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 06 Feb 2006 09:12:51 -0800 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <20060206170343.96873.qmail@web51514.mail.yahoo.com> References: <20060206170343.96873.qmail@web51514.mail.yahoo.com> Message-ID: <1139245971.3188.18.camel@yoda.loki.me> On Mon, 2006-02-06 at 09:03 -0800, Steve G wrote: > > Out of curiosity, when the rebuild occurs...does the script use an alphabetical > listing of the packages from a to z. Or does the script try to build the packages > in a somewhat ordered fashion from no dependencies (attr, zlib, bzip, etc) to > more complicated packages that have many dependencies (mkinitrd, pam, slang, > etc.) Mostly just an a to z thing. The way our current build system works, every package is installed into the build root, so at this point we're pretty assured that all build reqs will be met. This is not optimal for many reasons, and a replacement build system is being developed that fixes this. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ihok at hotmail.com Mon Feb 6 17:30:29 2006 From: ihok at hotmail.com (Jack Tanner) Date: Mon, 06 Feb 2006 12:30:29 -0500 Subject: Proposed and major updates policy In-Reply-To: <43E6AFC0.3010308@redhat.com> References: <43E4AC9E.2050907@fedoraproject.org> <200602041304.19683.lamont@gurulabs.com> <43E50A71.9060905@mharris.ca> <200602041319.03294.lamont@gurulabs.com> <43E62607.9070807@fedoraproject.org> <1139158188.2948.30.camel@localhost.localdomain> <604aa7910602051755y1ac6e85uaa9164f33b26fe5f@mail.gmail.com> <43E6AFC0.3010308@redhat.com> Message-ID: Warren Togami wrote: > Jeff Spaleta wrote: > >> The PERFECT solution.. is to integrate update notifications back into >> available client tools.. so noone has to dink around with any >> mailinglist at all to see update annoucements. In the perfect world, >> all you have to do is ask your client tool to give you a summary of >> relevant notifications for each repo you are interested in from the >> repo metadata. > > I strongly agree that users shouldn't need to fumble through mail in > order to read update announcements. This should be part of our package > metadata and easily browsable using package management tools. It's a nice solution if it's also available via the web. The various mailing list archives make it easy to follow the list of updates even if you're not logged into the system you need to update. If the only way of following update announcements is to run yum or some other client repodata-aware client tool, it becomes difficult to follow the announcements from machines without this client tool (e.g., Windows workstations), or from places like Internet cafes, where the only tool you have is a web browser. From jeff at ocjtech.us Mon Feb 6 17:57:29 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Mon, 06 Feb 2006 11:57:29 -0600 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <1139245971.3188.18.camel@yoda.loki.me> References: <20060206170343.96873.qmail@web51514.mail.yahoo.com> <1139245971.3188.18.camel@yoda.loki.me> Message-ID: <1139248650.2970.58.camel@lt16585.campus.dmacc.edu> On Mon, 2006-02-06 at 09:12 -0800, Jesse Keating wrote: > On Mon, 2006-02-06 at 09:03 -0800, Steve G wrote: > > > > Out of curiosity, when the rebuild occurs...does the script use an alphabetical > > listing of the packages from a to z. Or does the script try to build the packages > > in a somewhat ordered fashion from no dependencies (attr, zlib, bzip, etc) to > > more complicated packages that have many dependencies (mkinitrd, pam, slang, > > etc.) > > Mostly just an a to z thing. The way our current build system works, > every package is installed into the build root, so at this point we're > pretty assured that all build reqs will be met. This is not optimal for > many reasons, and a replacement build system is being developed that > fixes this. I know that yum/mock/plague doesn't quite fit the bill as a beehive replacement, but it would be nice if RedHat could work with the community to extend yum/mock/plague rather than re-inventing the wheel. I know that one thing that plague could use is a way to easily switch the plague client between two or more plague servers. 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 davej at redhat.com Mon Feb 6 19:59:13 2006 From: davej at redhat.com (Dave Jones) Date: Mon, 6 Feb 2006 14:59:13 -0500 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <1139243683.3188.14.camel@yoda.loki.me> References: <1139006387.2652.29.camel@bree.local.net> <1139014200.2863.65.camel@yoda.loki.me> <43E48DDD.4060508@vip.hr> <200602041255.23869.lamont@gurulabs.com> <43E5095E.3060804@mharris.ca> <43E6763A.8050509@uindy.edu> <43E7186E.7050307@redhat.com> <1139243683.3188.14.camel@yoda.loki.me> Message-ID: <20060206195913.GB30359@redhat.com> On Mon, Feb 06, 2006 at 08:34:43AM -0800, Jesse Keating wrote: > On Mon, 2006-02-06 at 04:35 -0500, Christopher Aillon wrote: > > Suspend should be working for FC5, especially on thinkpads. Works great > > on my T41 at least. > > > > Suspend on T42 yes. Resume? Kind of. I resume it goes RIGHT back to > sleep, so I have to fiddle w/ the lid button once to get it to wake back > up again. > How are you doing the suspend ? Are you writing to /sys/power/sleep yourself, or using a helper like pm-suspend ? pm-suspend should be doing all the necessary hacking around with the button module itself in latest builds. Dave From dax at gurulabs.com Mon Feb 6 20:08:36 2006 From: dax at gurulabs.com (Dax Kelson) Date: Mon, 06 Feb 2006 13:08:36 -0700 Subject: dmraid comments and a warning Message-ID: <1139256516.4440.66.camel@mentorng.gurulabs.com> It is understood that 'real' hardware RAID controllers are better than 'fake' RAID controllers commonly built into motherboards and cheap PCI cards. However, the 'fake' RAID is *extremely* common and is often used by someone already running Windows who then wants to free up some room to install and dual boot Linux. The (single?) advantage of the 'fake' RAID over Linux software RAID is no effort redundancy in booting because of the RAID BIOS integration. ==The Issue== Once a RAID1 (mirror) is has been defined and built inside of the BIOS the utility you *never ever* want to boot to half of the RAID. If you do, and you go back to booting to whole activated RAID, you get massive file corruption. Currently it is very easy for this to happen. I have been testing the dmraid support out on a test box with onboard Nvidia "nforce4" RAID and two mirrored drives. Twice I've gotten completely scrambled data and had to re-install from scratch. --Event One-- I installed rawhide a few weeks ago. Anaconda automatically activated the motherboard RAID. Cool! Inside of Anaconda's disk druid I elected to go the manual route and not setup LVM. Instead I defined: /dev/mapper/nvidia_foo1 -- /boot /dev/mapper/nvidia_foo2 -- swap /dev/mapper/nvidia_foo3 -- / GRUB installed fine, and all the packages installed OK. It rebooted OK, and I did a 'yum -y upgrade'. So far so good (or so it seemed). The standard root=LABEL=/ was used on the kernel command line and what happened is that it booted up to one side of the mirror. All the updates and new packages (including a new kernel install which modified the grub.conf) activity just happened on that one side of the mirror. When I rebooted, GRUB read a garbled grub.conf because at that stage ist *is* using a 'activated' RAID (via the RAID BIOS support). I couldn't boot. So I booted to the rescue environment, which did the right thing and activated the RAID and it even mounted the filesystems. When I went and inspected the files though, anything that got touched while it booted to the one side of the mirror was trashed. Result = dead Linux system --Event Two-- With the benefit of the experience of event one. I did a new install, but this time I let Anaconda's disk druid do the "auto setup" thing and create a LVM. I figured that LVM using device mapper and dmraid would always "do the right thing" in regards to *always* using the activated RAID partitions as the PVs. This seemed to be the case. I installed and booted OK. I verified that I was using LVM and inspected the physical volumes using 'pvdisplay'. I was greeted with: # pvdisplay --- Physical volume --- PV Name /dev/dm-1 [snip] Looks good! Seeing /dev/dm-1 instead of /dev/mapper was a surprise, but I agree with the idea. This was two or three weeks ago and I have been using the system and doing daily 'yum -y upgrade'. Yesterday or the day before I did the 'yum -y upgrade' and rebooted. On the GRUB screen it would not boot to the first listed kernel, with a read error on the kernel binary. Looking at the GRUB menu, I noticed some missing boot options (I had previously added memtest86 and there was a menu item to boot a Windows Partition). I was able to get a boot going choosing one of the older kernels. On bootup I noticed an error flash by something to the effect of "LVM ignoring duplicate PV". I ran pvdisplay and saw: # pvdisplay --- Physical volume --- PV Name /dev/sda1 [snip] It booted off one half of the mirror. It must have done the same on some previous boot. For fun (the Linux install was dead now of course, it just didn't know it) I ran a 'yum -y upgrade'. On a reboot GRUB listed 3 kernel choices, all of them gave read errors. Result (a) = dead Linux system Result (b) = inaccessible Windows system (if you don't know how to use the GRUB command line) ==Comments== There needs to be more checks in place to prevent booting off of one half of the mirror, or at a minimum only allowing a read-only boot on one side of the mirror. Dead systems are no fun. Loosing your personal data is hell. This isn't purely a Linux problem. Any operating system using fake RAID1 needs to be robust in this regard. I saw a Windows box using 'fake' motherboard RAID and the motherboard BIOS got flashed which reset the "Use RAID" setting to 'off'. Then Windows booted off of half the RAID. This was noticed and the BIOS setting was turned back on and a boot attempted. Massive corruption and a dead Windows system was the result. To Window's credit I haven't seen it accidentally boot off of half the RAID as long as the BIOS RAID was turned on and the drivers installed. The rules are: 1. Don't boot off half of the RAID1 in read-write mode 2. If rule 1 is violated, don't ever again boot using the RAID1 - If you can abide by rule 2, you can do so indefinitely 3. There is no way to recover from a violated rule 1 without reinstalling. Dax Kelson Guru Labs From jfrieben at freesurf.fr Mon Feb 6 20:10:21 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Mon, 6 Feb 2006 21:10:21 +0100 (CET) Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <20060206195913.GB30359@redhat.com> References: <20060206195913.GB30359@redhat.com> Message-ID: <44345.89.50.33.243.1139256621.squirrel@jose.freesurf.fr> "suspend" works like a charm on my T23. Install "gnome-power-manager" (which is not installed by default!) and choose the sleep method from the menu. > > How are you doing the suspend ? Are you writing to /sys/power/sleep > yourself, or using a helper like pm-suspend ? > > pm-suspend should be doing all the necessary hacking around with the > button module itself in latest builds. > > Dave > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From jkeating at j2solutions.net Mon Feb 6 20:03:54 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 06 Feb 2006 12:03:54 -0800 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <1139248650.2970.58.camel@lt16585.campus.dmacc.edu> References: <20060206170343.96873.qmail@web51514.mail.yahoo.com> <1139245971.3188.18.camel@yoda.loki.me> <1139248650.2970.58.camel@lt16585.campus.dmacc.edu> Message-ID: <1139256234.3188.32.camel@yoda.loki.me> On Mon, 2006-02-06 at 11:57 -0600, Jeffrey C. Ollie wrote: > > I know that yum/mock/plague doesn't quite fit the bill as a beehive > replacement, but it would be nice if RedHat could work with the > community to extend yum/mock/plague rather than re-inventing the wheel. > > I know that one thing that plague could use is a way to easily switch > the plague client between two or more plague servers. The new build system is mock based. We've been working very closely w/ the mock/plague folks. Remember, plague was heavily written by a RH employee (; -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-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 Feb 6 20:07:30 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 06 Feb 2006 12:07:30 -0800 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <20060206195913.GB30359@redhat.com> References: <1139006387.2652.29.camel@bree.local.net> <1139014200.2863.65.camel@yoda.loki.me> <43E48DDD.4060508@vip.hr> <200602041255.23869.lamont@gurulabs.com> <43E5095E.3060804@mharris.ca> <43E6763A.8050509@uindy.edu> <43E7186E.7050307@redhat.com> <1139243683.3188.14.camel@yoda.loki.me> <20060206195913.GB30359@redhat.com> Message-ID: <1139256450.3188.34.camel@yoda.loki.me> On Mon, 2006-02-06 at 14:59 -0500, Dave Jones wrote: > How are you doing the suspend ? Are you writing to /sys/power/sleep yourself, > or using a helper like pm-suspend ? > > pm-suspend should be doing all the necessary hacking around with the button > module itself in latest builds. I have gnome-power-manager running. To suspend to ram I just close the lid. To suspend to disk I right click on g-p-m and select hibernate. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From paul at cypherpunks.ca Mon Feb 6 20:28:23 2006 From: paul at cypherpunks.ca (Paul Wouters) Date: Mon, 6 Feb 2006 21:28:23 +0100 (CET) Subject: What is the proper way to fix 'make tag' and 'make plague' conflict Message-ID: Hey, Sometimes I am stupid and I forget to make tag after commiting my files and trying out make plague. You then end up in a situation where your release version exists in limbo: # make tag cvs tag -c fetchlog-1_0-3_fc5 For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs ? clog cvs tag: .cvsignore is locally modified ERROR: Tag fetchlog-1_0-3_fc5 has been already created. cvs tag: Pre-tag check failed cvs [tag aborted]: correct the above errors first! make: *** [tag] Error 1 [root at bofh devel]# make plague fetchlog.spec not tagged with tag fetchlog-1_0-3_fc5 make: *** [plague] Error 1 My fix so far has been to just bump the release, but that's rather ugly. Is there a "proper" fix for this situation (excluding brain surgery) Paul From katzj at redhat.com Mon Feb 6 20:24:48 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 06 Feb 2006 15:24:48 -0500 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <44345.89.50.33.243.1139256621.squirrel@jose.freesurf.fr> References: <20060206195913.GB30359@redhat.com> <44345.89.50.33.243.1139256621.squirrel@jose.freesurf.fr> Message-ID: <1139257488.13559.21.camel@bree.local.net> On Mon, 2006-02-06 at 21:10 +0100, Joachim Frieben wrote: > "suspend" works like a charm on my T23. Install "gnome-power-manager" (which > is not installed by default!) and choose the sleep method from the menu. It should now being installed by default if you install GNOME Jeremy From rdieter at math.unl.edu Mon Feb 6 20:52:55 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 06 Feb 2006 14:52:55 -0600 Subject: What is the proper way to fix 'make tag' and 'make plague' conflict In-Reply-To: References: Message-ID: <43E7B727.8070406@math.unl.edu> Paul Wouters wrote: > Sometimes I am stupid and I forget to make tag after commiting my files > and trying out make plague. You then end up in a situation where your > release version exists in limbo: > > # make tag > cvs tag -c fetchlog-1_0-3_fc5 > For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs > ? clog > cvs tag: .cvsignore is locally modified > ERROR: Tag fetchlog-1_0-3_fc5 has been already created. Increment Release, Redo: 'make tag', make 'build' -- Rex From mharris at mharris.ca Mon Feb 6 20:54:14 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 06 Feb 2006 15:54:14 -0500 Subject: Request for testers: Video hardware autodetection In-Reply-To: <43E766E2.8070908@cox.net> References: <43E4A50E.5070209@mharris.ca> <43E766E2.8070908@cox.net> Message-ID: <43E7B776.7060305@mharris.ca> Clyde E. Kunkel wrote: > Mike A. Harris wrote: > >> The latest xorg-x11-drv-* driver packages contain videoaliases >> files for kudzu et al. to use for video card autodetection and >> driver mapping. >> > > > > >> If you have a video card which is assigned the "vesa" driver >> from the above test, then it is either not supported by the >> drivers, or we're missing a PCI ID to driver mapping for that >> card/chip. To determine if it is supported by the driver, >> hand edit the xorg.conf and replace the vesa driver with the >> native X driver for the particular vendor. ie: "nv" for >> Nvidia, "ati" for ATI, etc., and test to see if X starts up. >> > > > 2/6/06 rawhide ati driver xorg-x11-drv-ati-6.5.7.3-3 still detects > radeon 9200 AGP as vesa. BZ 180001 updated. This is an odd situation, as it appears as if the videoalias files are being ignored by kudzu. The radeon.xinf does contain the entries for the Radeon 9200, so it should get detected. Are you running a fully updated system, including the latest kudzu, system-config-display, rhpl, rhplx, pyxf86config, all xorg packages, kernel, etc.? If one uses an old (FC4 era, or early FC5 rawhide) set of any of these packages, that would explain it. To make matters more confusing, other people are claiming the autodetection does work properly now. So I'd like to ask everyone to make absolutely sure their entire system is completely updated to current rawhide, and not just xorg packages. Also, systems running FC4 with some parts of rawhide will totally not work right as far as autodetection goes, but that is expected. If everyone is updated however, and the problem remains only for some people, then we'll have to investigate why that's happening, but it would sure be a strange situation. ;) Thanks for the update! -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From reuben-fedora-devel at reub.net Mon Feb 6 21:00:26 2006 From: reuben-fedora-devel at reub.net (Reuben Farrelly) Date: Tue, 07 Feb 2006 10:00:26 +1300 Subject: dmraid comments and a warning In-Reply-To: <1139256516.4440.66.camel@mentorng.gurulabs.com> References: <1139256516.4440.66.camel@mentorng.gurulabs.com> Message-ID: <43E7B8EA.9030000@reub.net> On 7/02/2006 9:08 a.m., Dax Kelson wrote: > This isn't purely a Linux problem. Any operating system using fake RAID1 > needs to be robust in this regard. I saw a Windows box using 'fake' > motherboard RAID and the motherboard BIOS got flashed which reset the > "Use RAID" setting to 'off'. Then Windows booted off of half the RAID. > This was noticed and the BIOS setting was turned back on and a boot > attempted. Massive corruption and a dead Windows system was the result. > To Window's credit I haven't seen it accidentally boot off of half the > RAID as long as the BIOS RAID was turned on and the drivers installed. Very interesting to read this post - as you're not the only one to have this problem. I had this exact same problem after a BIOS upgrade a few months back whereby all settings got reset and I booted up off one half of the raid - to find massive trashing after I went back in and fixed the BIOS setting and reactivated the second half of the raid and then rebooted. (read: ntdetect.com and friends did not exist anymore) It's the sort of stuff that should flag big red flashing boxes and warning messages appearing, but you like I, had to learn the hard way ;-) My box has a genuine Intel D945 board, so it's hardly a cheap-and-nasty piece of hardware even if it has a cheap and nasty type of RAID. At the time I put it down to a "don't do that, it's probably a BIOS bug which I'll never hit again" type issue. I suspect but haven't tested that the best way around the problem after this sort of unplanned configuration change is to completely wipe the second old/removed drive so it no longer looks like a RAID disk at all, fix the bios setting, boot up on the one original device and re-add the second drive as a new device in the array, while booted up under Windows. On my Linux server which is another box, I have disabled onboard RAID1 and use mdadm instead, which seems smarter (and safer) ;-) reuben From mharris at mharris.ca Mon Feb 6 21:05:00 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 06 Feb 2006 16:05:00 -0500 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <1139248650.2970.58.camel@lt16585.campus.dmacc.edu> References: <20060206170343.96873.qmail@web51514.mail.yahoo.com> <1139245971.3188.18.camel@yoda.loki.me> <1139248650.2970.58.camel@lt16585.campus.dmacc.edu> Message-ID: <43E7B9FC.4010901@mharris.ca> Jeffrey C. Ollie wrote: > On Mon, 2006-02-06 at 09:12 -0800, Jesse Keating wrote: > >>On Mon, 2006-02-06 at 09:03 -0800, Steve G wrote: >> >>>Out of curiosity, when the rebuild occurs...does the script use an alphabetical >>>listing of the packages from a to z. Or does the script try to build the packages >>>in a somewhat ordered fashion from no dependencies (attr, zlib, bzip, etc) to >>>more complicated packages that have many dependencies (mkinitrd, pam, slang, >>>etc.) >> >>Mostly just an a to z thing. The way our current build system works, >>every package is installed into the build root, so at this point we're >>pretty assured that all build reqs will be met. This is not optimal for >>many reasons, and a replacement build system is being developed that >>fixes this. > > > I know that yum/mock/plague doesn't quite fit the bill as a beehive > replacement, but it would be nice if RedHat could work with the > community to extend yum/mock/plague rather than re-inventing the wheel. > > I know that one thing that plague could use is a way to easily switch > the plague client between two or more plague servers. s/RedHat/Red Hat/ Would it make that much of a difference though, or would people still say the same thing? I think even if Red Hat devoted 2 or more employees working full time on mock/plague that people would still say the same thing. Why do I think that? Well for starters, Red Hat has contributed quite a lot to plague already from what I understand. I don't know the level of contribution to mock, but it gets heavy usage internally by individuals, and our next generation buildsystem is aparently based on mock/plague. What more exactly are you looking for? I suppose Red Hat could in theory hire every single person who has contributed to either project... ;o) But then there would be conspiracy theories about something else right? ;o) -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From rodd at clarkson.id.au Mon Feb 6 21:29:29 2006 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 07 Feb 2006 08:29:29 +1100 Subject: Request for testers: Video hardware autodetection In-Reply-To: <43E4A50E.5070209@mharris.ca> References: <43E4A50E.5070209@mharris.ca> Message-ID: <1139261369.24225.1.camel@localhost.localdomain> On Sat, 2006-02-04 at 07:58 -0500, Mike A. Harris wrote: > So, for the shortterm, I'd like everyone to make a backup copy > of your xorg.conf, and to test the latest drivers with > "system-config-display --reconfig" to ensure that your video > hardware is autodetected properly. This nvidia controller: 01:00.0 VGA compatible controller: nVidia Corporation NV41.8 [GeForce Go 6800] (rev a2) is detected properly. R. -- "It's a fine line between denial and faith. It's much better on my side" From linux_4ever at yahoo.com Mon Feb 6 21:31:36 2006 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 6 Feb 2006 13:31:36 -0800 (PST) Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <1139245971.3188.18.camel@yoda.loki.me> Message-ID: <20060206213136.89786.qmail@web51506.mail.yahoo.com> >Mostly just an a to z thing. Aren't there a couple packages or programs that uses static linking? That's really the basis of my concern. >The way our current build system works, every package is installed into the build >root, so at this point we're pretty assured that all build reqs will be met. Its not about whether requirements are met. Its what anything that does static linking is linked with. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From notting at redhat.com Mon Feb 6 21:33:04 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 6 Feb 2006 16:33:04 -0500 Subject: Request for testers: Video hardware autodetection In-Reply-To: <43E7B776.7060305@mharris.ca> References: <43E4A50E.5070209@mharris.ca> <43E766E2.8070908@cox.net> <43E7B776.7060305@mharris.ca> Message-ID: <20060206213304.GC14730@devserv.devel.redhat.com> Mike A. Harris (mharris at mharris.ca) said: > If everyone is updated however, and the problem remains only for > some people, then we'll have to investigate why that's happening, > but it would sure be a strange situation. ;) I believe the cases that are failing are all dual-head Radeon (and similar) cards that have two PCI devices, and s-c-display is, for some reason, always picking the second device. Bill From rodd at clarkson.id.au Mon Feb 6 21:46:43 2006 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 07 Feb 2006 08:46:43 +1100 Subject: rawhide report: 20060202 changes In-Reply-To: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> Message-ID: <1139262403.24225.5.camel@localhost.localdomain> On Thu, 2006-02-02 at 10:53 -0500, Build System wrote: > f-spot-0.1.8-2 > -------------- > * Wed Feb 01 2006 Christopher Aillon - 0.1.8-2 > - Add sqlite3.patch to ensure that sqlite3 is used if both > sqlite2 and sqlite3 are installed. > Trying to run f-spot I get: [rodd at localhost ~]$ f-spot & [1] 24613 [rodd at localhost ~]$ Starting new FSpot server Unhandled Exception: Mono.Data.SqliteClient.SqliteSyntaxException: file is encrypted or is not a database in [0x0007f] Mono.Data.SqliteClient.SqliteCommand:GetNextStatement (IntPtr pzStart, System.IntPtr pzTail, System.IntPtr pStmt) in [0x00022] (at /usr/src/build/687862-i386/BUILD/mono-1.1.13.2/mcs/class/Mono.Data.SqliteClient/Mono.Data.SqliteClient/SqliteCommand.cs:459) Mono.Data.SqliteClient.SqliteCommand:ExecuteReader (CommandBehavior behavior, Boolean want_results, System.Int32 rows_affected) in [0x00005] (at /usr/src/build/687862-i386/BUILD/mono-1.1.13.2/mcs/class/Mono.Data.SqliteClient/Mono.Data.SqliteClient/SqliteCommand.cs:435) Mono.Data.SqliteClient.SqliteCommand:ExecuteReader (CommandBehavior behavior) in [0x00002] (at /usr/src/build/687862-i386/BUILD/mono-1.1.13.2/mcs/class/Mono.Data.SqliteClient/Mono.Data.SqliteClient/SqliteCommand.cs:429) Mono.Data.SqliteClient.SqliteCommand:ExecuteReader () in <0x00092> TagStore:LoadAllTags () in <0x0005c> TagStore:.ctor (Mono.Data.SqliteClient.SqliteConnection connection, Boolean is_new) in <0x000c7> Db:.ctor (System.String path, Boolean create_if_missing) in <0x002f1> Driver:Main (System.String[] args) [1]+ Exit 1 f-spot [rodd at localhost ~]$ Do I bugzilla? R. -- "It's a fine line between denial and faith. It's much better on my side" From katzj at redhat.com Mon Feb 6 21:54:16 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 06 Feb 2006 16:54:16 -0500 Subject: rawhide report: 20060202 changes In-Reply-To: <1139262403.24225.5.camel@localhost.localdomain> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> <1139262403.24225.5.camel@localhost.localdomain> Message-ID: <1139262856.13559.64.camel@bree.local.net> On Tue, 2006-02-07 at 08:46 +1100, Rodd Clarkson wrote: > Trying to run f-spot I get: [snip] > Do I bugzilla? This is due to the move from sqlite2 -> sqlite3 changing the db format which f-spot doesn't handle that well. Probably worth a bugzilla, although as we haven't "shipped" a sqlite2 based version, it might not be the highest priority thing to handle Jeremy From igorm5 at vip.hr Mon Feb 6 22:10:58 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Mon, 06 Feb 2006 23:10:58 +0100 Subject: rawhide report: 20060202 changes In-Reply-To: <1139262403.24225.5.camel@localhost.localdomain> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> <1139262403.24225.5.camel@localhost.localdomain> Message-ID: <43E7C972.2010508@vip.hr> Rodd Clarkson wrote: > On Thu, 2006-02-02 at 10:53 -0500, Build System wrote: >>f-spot-0.1.8-2 >>-------------- >>* Wed Feb 01 2006 Christopher Aillon - 0.1.8-2 >>- Add sqlite3.patch to ensure that sqlite3 is used if both >> sqlite2 and sqlite3 are installed. > Trying to run f-spot I get: > [rodd at localhost ~]$ f-spot & > [1] 24613 > [rodd at localhost ~]$ Starting new FSpot server ... > Do I bugzilla? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179983 -- Igor Jagec From clydekunkel7734 at cox.net Mon Feb 6 23:25:23 2006 From: clydekunkel7734 at cox.net (Clyde E. Kunkel) Date: Mon, 06 Feb 2006 18:25:23 -0500 Subject: Request for testers: Video hardware autodetection In-Reply-To: <43E7B776.7060305@mharris.ca> References: <43E4A50E.5070209@mharris.ca> <43E766E2.8070908@cox.net> <43E7B776.7060305@mharris.ca> Message-ID: <43E7DAE3.8060300@cox.net> Mike A. Harris wrote: > Clyde E. Kunkel wrote: >> Mike A. Harris wrote: >> >>> The latest xorg-x11-drv-* driver packages contain videoaliases >>> files for kudzu et al. to use for video card autodetection and >>> driver mapping. >>> >> >> >> >> >>> If you have a video card which is assigned the "vesa" driver >>> from the above test, then it is either not supported by the >>> drivers, or we're missing a PCI ID to driver mapping for that >>> card/chip. To determine if it is supported by the driver, >>> hand edit the xorg.conf and replace the vesa driver with the >>> native X driver for the particular vendor. ie: "nv" for >>> Nvidia, "ati" for ATI, etc., and test to see if X starts up. >>> >> >> >> 2/6/06 rawhide ati driver xorg-x11-drv-ati-6.5.7.3-3 still detects >> radeon 9200 AGP as vesa. BZ 180001 updated. > > This is an odd situation, as it appears as if the videoalias files > are being ignored by kudzu. The radeon.xinf does contain the entries > for the Radeon 9200, so it should get detected. Are you running > a fully updated system, including the latest kudzu, > system-config-display, rhpl, rhplx, pyxf86config, all xorg packages, > kernel, etc.? > > If one uses an old (FC4 era, or early FC5 rawhide) set of any of these > packages, that would explain it. > > To make matters more confusing, other people are claiming the > autodetection does work properly now. So I'd like to ask everyone > to make absolutely sure their entire system is completely updated > to current rawhide, and not just xorg packages. Also, systems > running FC4 with some parts of rawhide will totally not work right > as far as autodetection goes, but that is expected. > situation exist > If everyone is updated however, and the problem remains only for > some people, then we'll have to investigate why that's happening, > but it would sure be a strange situation. ;) > > Thanks for the update! > > > what is rhplx? reran "yum update" and got no updates. Went to another similar system that has a clean install of FC5T2 and yum updated daily (and verified again) and same vesa driver created in xorg.conf. This system has a radeon 9200 AGP AND a radeon 9200 SE PCI. For the original system (which is, BTW, a FC3 install, updated almost daily from rawhide): [root at P4C800ED ~]# rpm -qa kudzu system-config-display rhpl rhplx pyxf86config kernel-smp xorg* | sort kernel-smp-2.6.15-1.1878_FC5 kernel-smp-2.6.15-1.1881_FC5 kernel-smp-2.6.15-1.1884_FC5 kernel-smp-2.6.15-1.1895_FC5 kernel-smp-2.6.15-1.1898_FC5 kernel-smp-2.6.15-1.1907_FC5 kernel-smp-2.6.15-1.1909_FC5 kudzu-1.2.24-1 pyxf86config-0.3.22-1 rhpl-0.181-1 system-config-display-1.0.36-1 xorg-x11-apps-1.0.1-1 xorg-x11-drivers-0.99.2-4 xorg-x11-drv-acecad-1.0.0.5-1 xorg-x11-drv-aiptek-1.0.0.5-1 xorg-x11-drv-apm-1.0.1.5-1 xorg-x11-drv-ark-0.5.0.5-1 xorg-x11-drv-ati-6.5.7.3-3 xorg-x11-drv-calcomp-1.0.0.5-1 xorg-x11-drv-chips-1.0.1.3-1 xorg-x11-drv-cirrus-1.0.0.5-1 xorg-x11-drv-citron-2.1.1.5-1 xorg-x11-drv-cyrix-1.0.0.5-1 xorg-x11-drv-digitaledge-1.0.1.3-1 xorg-x11-drv-dmc-1.0.0.5-1 xorg-x11-drv-dummy-0.1.0.5-1 xorg-x11-drv-dynapro-1.0.0.5-1 xorg-x11-drv-elo2300-1.0.0.5-1 xorg-x11-drv-elographics-1.0.0.5-1 xorg-x11-drv-evdev-1.0.0.5-1 xorg-x11-drv-fbdev-0.1.0.5-1 xorg-x11-drv-fpit-1.0.0.5-1 xorg-x11-drv-glint-1.0.1.3-1 xorg-x11-drv-hyperpen-1.0.0.5-1 xorg-x11-drv-i128-1.1.0.5-1 xorg-x11-drv-i740-1.0.0.5-1 xorg-x11-drv-i810-1.4.1.3-3 xorg-x11-drv-jamstudio-1.0.0.5-1 xorg-x11-drv-joystick-1.0.0.5-1 xorg-x11-drv-keyboard-1.0.1.3-1 xorg-x11-drv-magellan-1.0.0.5-1 xorg-x11-drv-magictouch-1.0.0.5-1 xorg-x11-drv-mga-1.2.1.3-1 xorg-x11-drv-microtouch-1.0.0.5-1 xorg-x11-drv-mouse-1.0.3.1-1 xorg-x11-drv-mutouch-1.0.0.5-1 xorg-x11-drv-neomagic-1.0.0.5-1 xorg-x11-drv-nsc-2.7.6.5-2 xorg-x11-drv-nv-1.0.1.5-1 xorg-x11-drv-palmax-1.0.0.5-1 xorg-x11-drv-penmount-1.0.0.5-1 xorg-x11-drv-rendition-4.0.1.3-1 xorg-x11-drv-s3-0.3.5.5-1 xorg-x11-drv-s3virge-1.8.6.5-1 xorg-x11-drv-savage-2.0.2.3-1 xorg-x11-drv-siliconmotion-1.3.1.5-1 xorg-x11-drv-sis-0.8.1.3-1 xorg-x11-drv-sisusb-0.7.1.3-1 xorg-x11-drv-spaceorb-1.0.0.5-1 xorg-x11-drv-summa-1.0.0.5-1 xorg-x11-drv-tdfx-1.1.1.3-1 xorg-x11-drv-trident-1.0.1.2-1 xorg-x11-drv-tseng-1.0.0.5-1 xorg-x11-drv-ur98-1.0.0.5-1 xorg-x11-drv-vesa-1.0.1.3-1 xorg-x11-drv-vga-4.0.0.5-1 xorg-x11-drv-via-0.1.33.2-1 xorg-x11-drv-vmware-10.11.1.3-1 xorg-x11-drv-void-1.0.0.5-1 xorg-x11-drv-voodoo-1.0.0.5-1 xorg-x11-filesystem-0.99.2-3 xorg-x11-fonts-100dpi-7.0-1 xorg-x11-fonts-75dpi-7.0-1 xorg-x11-fonts-base-7.0-1 xorg-x11-fonts-ISO8859-1-100dpi-7.0-1 xorg-x11-fonts-ISO8859-1-75dpi-7.0-1 xorg-x11-fonts-misc-7.0-1 xorg-x11-fonts-Type1-7.0-1 xorg-x11-font-utils-1.0.1-1 xorg-x11-proto-devel-7.0-1 xorg-x11-resutils-1.0.1-1 xorg-x11-server-utils-1.0.1-1 xorg-x11-server-Xnest-1.0.1-1 xorg-x11-server-Xorg-1.0.1-1 xorg-x11-twm-1.0.1-1 xorg-x11-utils-1.0.1-1 xorg-x11-xauth-1.0.1-1 xorg-x11-xdm-1.0.1-1 xorg-x11-xfs-1.0.1-1 xorg-x11-xfwp-1.0.1-1 xorg-x11-xinit-1.0.1-1 xorg-x11-xkbdata-1.0.1-1 xorg-x11-xkb-utils-1.0.1-1 xorg-x11-xsm-1.0.1-1 [root at P4C800ED ~]# rpm -q rhplx package rhplx is not installed [root at P4C800ED ~]# yum install rhplx Setting up Install Process Setting up repositories extras-dev: ################################################## 3/3 Reading repository metadata in from local files Parsing package install arguments No Match for argument: rhplx Nothing to do [root at P4C800ED ~]# -- Regards, Old Fart (my reply-to address is "munged" to defeat spambots) From nalin at redhat.com Mon Feb 6 23:30:19 2006 From: nalin at redhat.com (Nalin Dahyabhai) Date: Mon, 6 Feb 2006 18:30:19 -0500 Subject: Request for testers: Video hardware autodetection In-Reply-To: <43E7DAE3.8060300@cox.net> References: <43E4A50E.5070209@mharris.ca> <43E766E2.8070908@cox.net> <43E7B776.7060305@mharris.ca> <43E7DAE3.8060300@cox.net> Message-ID: <20060206233018.GH17034@redhat.com> On Mon, Feb 06, 2006 at 06:25:23PM -0500, Clyde E. Kunkel wrote: > what is rhplx? It's "rhpxl" spelled incorrectly. HTH, Nalin From ndbecker2 at gmail.com Tue Feb 7 00:07:12 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Mon, 06 Feb 2006 19:07:12 -0500 Subject: digikam(extras) conflicts with koffice(devel) Message-ID: Transaction Check Error: file /usr/share/mimelnk/image/x-raw.desktop from install of koffice-core-1.4.90-2.fc5 conflicts with file from package digikam-0.8.1-1.fc5 From clydekunkel7734 at cox.net Tue Feb 7 00:11:11 2006 From: clydekunkel7734 at cox.net (Clyde E. Kunkel) Date: Mon, 06 Feb 2006 19:11:11 -0500 Subject: Request for testers: Video hardware autodetection In-Reply-To: <20060206233018.GH17034@redhat.com> References: <43E4A50E.5070209@mharris.ca> <43E766E2.8070908@cox.net> <43E7B776.7060305@mharris.ca> <43E7DAE3.8060300@cox.net> <20060206233018.GH17034@redhat.com> Message-ID: <43E7E59F.5040408@cox.net> Nalin Dahyabhai wrote: > On Mon, Feb 06, 2006 at 06:25:23PM -0500, Clyde E. Kunkel wrote: >> what is rhplx? > > It's "rhpxl" spelled incorrectly. > > HTH, > > Nalin > Thanks. [root at P4C800ED ~]# rpm -q rhpxl rhpxl-0.13-1 [root at P4C800ED ~]# -- Regards, Old Fart (my reply-to address is "munged" to defeat spambots) From mailinglists at erwinrol.com Tue Feb 7 01:43:38 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Tue, 07 Feb 2006 02:43:38 +0100 Subject: trying to install rawhide Message-ID: <1139276618.8135.31.camel@xpc.home.erwinrol.com> I have been trying to install the current rawhide on a older machine, to test if it works (my current rawhide machine is just an yum updated FC4). But I don't get very far, It boots OK, than i get the language and keyboard selection. I select US keyboard and than my A and Q and my W and Y keys are switched, and probably a lot of other keys too. Ignoring the weird keyboard i select http install, and than get the Message "Running anaconda, The Fedora System Installer - please wait" and pretty much directly after that "install exited abnormally" and there my install adventure is over. It anybody actually using/testing the install system, or is it just there for show until the next test release is here ? - Erwin From cmadams at hiwaay.net Tue Feb 7 01:54:05 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 6 Feb 2006 19:54:05 -0600 Subject: trying to install rawhide In-Reply-To: <1139276618.8135.31.camel@xpc.home.erwinrol.com> References: <1139276618.8135.31.camel@xpc.home.erwinrol.com> Message-ID: <20060207015405.GE742422@hiwaay.net> Once upon a time, Erwin Rol said: > Ignoring the weird keyboard i select http install, and than get the > Message "Running anaconda, The Fedora System Installer - please wait" > and pretty much directly after that "install exited abnormally" and > there my install adventure is over. Do you get a traceback? > It anybody actually using/testing the install system, or is it just > there for show until the next test release is here ? I have done a few rawhide installs from scratch lately (including one that just finished a few minutes ago, although that was an NFS install). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From pjones at redhat.com Tue Feb 7 02:02:06 2006 From: pjones at redhat.com (Peter Jones) Date: Mon, 06 Feb 2006 21:02:06 -0500 Subject: dmraid comments and a warning In-Reply-To: <1139256516.4440.66.camel@mentorng.gurulabs.com> References: <1139256516.4440.66.camel@mentorng.gurulabs.com> Message-ID: <1139277727.1654.28.camel@localhost.localdomain> On Mon, 2006-02-06 at 13:08 -0700, Dax Kelson wrote: [...] > Once a RAID1 (mirror) is has been defined and built inside of the BIOS > the utility you *never ever* want to boot to half of the RAID. If you > do, and you go back to booting to whole activated RAID, you get massive > file corruption. Well, that's not necessarily true, although for practical purposes it's currently true with dmraid. In a nice blue sky world, you've got block maps of what's in sync, and they've got a timestamp, and one of them is "correct". After all, you have to be able to re-sync from somewhere when one half of the mirror dies. But right now we can't really do that for most dmraid formats, I think. > The standard root=LABEL=/ was used on the kernel command line and what > happened is that it booted up to one side of the mirror. All the updates > and new packages (including a new kernel install which modified the > grub.conf) activity just happened on that one side of the mirror. This should be fixed in the current rawhide tree. > When I rebooted, GRUB read a garbled grub.conf because at that stage ist > *is* using a 'activated' RAID (via the RAID BIOS support). I couldn't > boot. What do you mean by "garbled" here? From what you've said so far, at this point you should have two perfectly coherent filesystems -- which just don't match. Each of them should have a grub.conf, both of which should be properly formed -- one of them just doesn't match one disk. > So I booted to the rescue environment, which did the right thing and > activated the RAID and it even mounted the filesystems. When I went and > inspected the files though, anything that got touched while it booted to > the one side of the mirror was trashed. So the Really Important Thing about BIOS-based raids is that if you _ever_ get into the situation where one disk has been written and the other hasn't, you need to go into your bios and re-sync the disks. And unfortunately, it's very difficult to automatically detect that you're in this situation with bios raid. > --Event Two-- > > With the benefit of the experience of event one. I did a new install, > but this time I let Anaconda's disk druid do the "auto setup" thing and > create a LVM. I figured that LVM using device mapper and dmraid would > always "do the right thing" in regards to *always* using the activated > RAID partitions as the PVs. What distro were you installing? AFAIK, both this and your previous configuration should have worked if you installed on a tree after January 9th or so. That'd mean test2 should have been ok. (I haven't really looked at upgrades yet; hopefully very soon even though it's not really possible to be "upgrading" from a fc4 dmraid setup.) > This seemed to be the case. I installed and booted OK. I verified that I > was using LVM and inspected the physical volumes using 'pvdisplay'. > > I was greeted with: > > # pvdisplay > --- Physical volume --- > PV Name /dev/dm-1 > [snip] > > Looks good! Seeing /dev/dm-1 instead of /dev/mapper was a surprise, but > I agree with the idea. Yeah, I hate our naming policies with all that. Having /dev/mapper/$MAP_NAME not correspond with the name in /sys/block is totally bogus, but it's what all of the device-mapper code does right now. > On bootup I noticed an error flash by something to the effect of "LVM > ignoring duplicate PV". Ok, so this means one of several possible things: 1) you're using lvm2 < 2.02.01-1 2) there's no entry for the dm device in /etc/blkid.tab 3) for some reason, the priority isn't set on the dm device in /etc/blkid.tab 4) there's no dm rules in your initrd I think that's actually the whole list of practical reasons you'd get to this point, but it's always possible I've overlooked something. One interesting note is that given any of these you should be getting the same disk mounted each time. Which means there's a good chance that sda and sdb are both fine, one of them just happens to represent your machine 3 weeks ago. I do still need to add more checking at boot time to bring it up read-only with a dm-error device as one half of the mirror, though, at which time it may even work to try and boot (read-only of course ;) once you've yanked sdb out. > I ran pvdisplay and saw: > > # pvdisplay > --- Physical volume --- > PV Name /dev/sda1 > [snip] > > It booted off one half of the mirror. It must have done the same on some > previous boot. Do you still have this disk set, or have you wiped it and reinstalled already? If you've got it, I'd like to see /etc/blkid.tab from either disk (both if possible). > There needs to be more checks in place to prevent booting off of one > half of the mirror, or at a minimum only allowing a read-only boot on > one side of the mirror. Dead systems are no fun. Loosing your personal > data is hell. Well, we should have the appropriate checks there at this point -- so I'd be curious to find out exactly which versions you installed with. It could be that one of the checks was introduced after you installed, and the "yum update" process caused it to believe it was *not* a raid system. (I haven't been extensively checking to make sure every daily rawhide would work perfectly as an update from the previous one, just that they'd install if possible...) > This isn't purely a Linux problem. Any operating system using fake RAID1 > needs to be robust in this regard. I saw a Windows box using 'fake' > motherboard RAID and the motherboard BIOS got flashed which reset the > "Use RAID" setting to 'off'. Then Windows booted off of half the RAID. That's interesting. It means there's some way to query the BIOS to tell if it's installed the int13 "raid" hook or not. I wish I knew what that magic is. > This was noticed and the BIOS setting was turned back on and a boot > attempted. Massive corruption and a dead Windows system was the result. > To Window's credit I haven't seen it accidentally boot off of half the > RAID as long as the BIOS RAID was turned on and the drivers installed. Of course you're also not using windows development trees ;) > The rules are: > 1. Don't boot off half of the RAID1 in read-write mode Yeah, we definitely still need some fallback stuff here. > 2. If rule 1 is violated, don't ever again boot using the RAID1 > - If you can abide by rule 2, you can do so indefinitely This isn't enforceable in any meaningful way in the software. In fact, it's scarcely even detectable currently :/ > 3. There is no way to recover from a violated rule 1 without > reinstalling. That's not the case -- you can go into the bios and sync from the "newer" disk to the older one. Or if your bios is total junk, you can boot some other media and (carefully) re-sync each partition with "dd". Thanks for the testing and feedback! -- Peter, wishing there was some way to tell the kernel to forget about partitions which have already been scanned... From pjones at redhat.com Tue Feb 7 02:32:22 2006 From: pjones at redhat.com (Peter Jones) Date: Mon, 06 Feb 2006 21:32:22 -0500 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <1139243683.3188.14.camel@yoda.loki.me> References: <1139006387.2652.29.camel@bree.local.net> <1139014200.2863.65.camel@yoda.loki.me> <43E48DDD.4060508@vip.hr> <200602041255.23869.lamont@gurulabs.com> <43E5095E.3060804@mharris.ca> <43E6763A.8050509@uindy.edu> <43E7186E.7050307@redhat.com> <1139243683.3188.14.camel@yoda.loki.me> Message-ID: <1139279542.1654.34.camel@localhost.localdomain> On Mon, 2006-02-06 at 08:34 -0800, Jesse Keating wrote: > On Mon, 2006-02-06 at 04:35 -0500, Christopher Aillon wrote: > > Suspend should be working for FC5, especially on thinkpads. Works great > > on my T41 at least. > > > > Suspend on T42 yes. Resume? Kind of. I resume it goes RIGHT back to > sleep, so I have to fiddle w/ the lid button once to get it to wake back > up again. Hrm. Does it actually go back to sleep, or just turn the screen off? Can you ping it? What video card do you have? -- Peter From katzj at redhat.com Tue Feb 7 02:39:30 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 06 Feb 2006 21:39:30 -0500 Subject: trying to install rawhide In-Reply-To: <1139276618.8135.31.camel@xpc.home.erwinrol.com> References: <1139276618.8135.31.camel@xpc.home.erwinrol.com> Message-ID: <1139279970.3100.4.camel@bree.local.net> On Tue, 2006-02-07 at 02:43 +0100, Erwin Rol wrote: > I have been trying to install the current rawhide on a older machine, to > test if it works (my current rawhide machine is just an yum updated > FC4). > > But I don't get very far, It boots OK, than i get the language and > keyboard selection. I select US keyboard and than my A and Q and my W > and Y keys are switched, and probably a lot of other keys too. Yeah, somehow the us layout became azerty instead... there's nothing in the logs to really help in figuring out why. The x86_64 tree is fine. So, we're going to see if it goes away tomorrow (in which case, it could just be something weird on a specific build machine) > Ignoring the weird keyboard i select http install, and than get the > Message "Running anaconda, The Fedora System Installer - please wait" > and pretty much directly after that "install exited abnormally" and > there my install adventure is over. Hmm, can you switch to tty3 and see what the last thing printed there? > It anybody actually using/testing the install system, or is it just > there for show until the next test release is here ? We're testing and fixing things as fast as we can -- unfortunately, we're not perfect yet :-) Jeremy From jkeating at j2solutions.net Tue Feb 7 02:39:43 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 06 Feb 2006 18:39:43 -0800 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <1139279542.1654.34.camel@localhost.localdomain> References: <1139006387.2652.29.camel@bree.local.net> <1139014200.2863.65.camel@yoda.loki.me> <43E48DDD.4060508@vip.hr> <200602041255.23869.lamont@gurulabs.com> <43E5095E.3060804@mharris.ca> <43E6763A.8050509@uindy.edu> <43E7186E.7050307@redhat.com> <1139243683.3188.14.camel@yoda.loki.me> <1139279542.1654.34.camel@localhost.localdomain> Message-ID: <1139279983.2697.16.camel@ender> On Mon, 2006-02-06 at 21:32 -0500, Peter Jones wrote: > > Hrm. Does it actually go back to sleep, or just turn the screen off? Back to sleep. I see dmesg saying "Entering memsleep" or something like that. The moon lights up on my laptop too. > Can you ping it? I haven't tried to yet, but I'm pretty sure I can't. > What video card do you have? 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pjones at redhat.com Tue Feb 7 02:45:28 2006 From: pjones at redhat.com (Peter Jones) Date: Mon, 06 Feb 2006 21:45:28 -0500 Subject: rawhide report: 20060202 changes In-Reply-To: <95ac75570602061838j1038ffa1nc7e730f0a39dd394@mail.gmail.com> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> <1139262403.24225.5.camel@localhost.localdomain> <95ac75570602061838j1038ffa1nc7e730f0a39dd394@mail.gmail.com> Message-ID: <1139280329.1654.36.camel@localhost.localdomain> On Mon, 2006-02-06 at 18:38 -0800, Alain Mellan wrote: > I get the same error w/ Beagle. > > BTW, upgrading to sqlite 3.3.3-1 still send yum in infinite loop. Had > to downgrade to 3.3.2. You need to update python-sqlite . -- Peter From michael at knox.net.nz Tue Feb 7 02:54:41 2006 From: michael at knox.net.nz (Michael J Knox) Date: Tue, 07 Feb 2006 15:54:41 +1300 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <1139279983.2697.16.camel@ender> References: <1139006387.2652.29.camel@bree.local.net> <1139014200.2863.65.camel@yoda.loki.me> <43E48DDD.4060508@vip.hr> <200602041255.23869.lamont@gurulabs.com> <43E5095E.3060804@mharris.ca> <43E6763A.8050509@uindy.edu> <43E7186E.7050307@redhat.com> <1139243683.3188.14.camel@yoda.loki.me> <1139279542.1654.34.camel@localhost.localdomain> <1139279983.2697.16.camel@ender> Message-ID: <1139280881.3462.0.camel@cosima.et.endace.com> On Mon, 2006-02-06 at 18:39 -0800, Jesse Keating wrote: > On Mon, 2006-02-06 at 21:32 -0500, Peter Jones wrote: > > > > Hrm. Does it actually go back to sleep, or just turn the screen off? > > Back to sleep. I see dmesg saying "Entering memsleep" or something like > that. The moon lights up on my laptop too. > > > Can you ping it? > > I haven't tried to yet, but I'm pretty sure I can't. > > > What video card do you have? > > 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] My laptop, a Toshiba A10, goes to sleep, but never returns. Probably file a bug report tonight. Michael From a.kurtz at hardsun.net Tue Feb 7 02:58:42 2006 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Mon, 06 Feb 2006 18:58:42 -0800 Subject: What is the proper way to fix 'make tag' and 'make plague' conflict In-Reply-To: References: Message-ID: <1139281123.6599.1.camel@nene.hardsun.net> On Mon, 2006-02-06 at 21:28 +0100, Paul Wouters wrote: > Hey, > > Sometimes I am stupid and I forget to make tag after commiting my files > and trying out make plague. You then end up in a situation where your > release version exists in limbo: > > My fix so far has been to just bump the release, but that's rather ugly. > Is there a "proper" fix for this situation (excluding brain surgery) make tag TAG_OPTS=-F to force it to tag. -- Aaron Kurtz From rodd at clarkson.id.au Tue Feb 7 03:11:43 2006 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 07 Feb 2006 14:11:43 +1100 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <1139279983.2697.16.camel@ender> References: <1139006387.2652.29.camel@bree.local.net> <1139014200.2863.65.camel@yoda.loki.me> <43E48DDD.4060508@vip.hr> <200602041255.23869.lamont@gurulabs.com> <43E5095E.3060804@mharris.ca> <43E6763A.8050509@uindy.edu> <43E7186E.7050307@redhat.com> <1139243683.3188.14.camel@yoda.loki.me> <1139279542.1654.34.camel@localhost.localdomain> <1139279983.2697.16.camel@ender> Message-ID: <1139281903.3336.2.camel@localhost.localdomain> I've got a dell inspiron 9300. On Mon, 2006-02-06 at 18:39 -0800, Jesse Keating wrote: > On Mon, 2006-02-06 at 21:32 -0500, Peter Jones wrote: > > > > Hrm. Does it actually go back to sleep, or just turn the screen off? > > Back to sleep. I see dmesg saying "Entering memsleep" or something like > that. The moon lights up on my laptop too. My power light glows on and off > > Can you ping it? > > I haven't tried to yet, but I'm pretty sure I can't. Haven't tried either, but I'm pretty sure I couldn't either. > > What video card do you have? > > 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] > 01:00.0 VGA compatible controller: nVidia Corporation NV41.8 [GeForce Go 6800] (rev a2) The box suspends (using gnome-power-manager), but when I press the power button to resume, it does stuff, but the screen never lights up and so far I've had to hold the power button until it reboots each time. (I'll try pinging at this point tonight too) R. -- "It's a fine line between denial and faith. It's much better on my side" From rodd at clarkson.id.au Tue Feb 7 03:15:17 2006 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 07 Feb 2006 14:15:17 +1100 Subject: rawhide report: 20060202 changes In-Reply-To: <43E7C972.2010508@vip.hr> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> <1139262403.24225.5.camel@localhost.localdomain> <43E7C972.2010508@vip.hr> Message-ID: <1139282117.3336.5.camel@localhost.localdomain> On Mon, 2006-02-06 at 23:10 +0100, Igor Jagec wrote: > Rodd Clarkson wrote: > > > On Thu, 2006-02-02 at 10:53 -0500, Build System wrote: > >>f-spot-0.1.8-2 > >>-------------- > >>* Wed Feb 01 2006 Christopher Aillon - 0.1.8-2 > >>- Add sqlite3.patch to ensure that sqlite3 is used if both > >> sqlite2 and sqlite3 are installed. > > Trying to run f-spot I get: > > [rodd at localhost ~]$ f-spot & > > [1] 24613 > > [rodd at localhost ~]$ Starting new FSpot server > ... > > Do I bugzilla? > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179983 Hmmm, tried this and got: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, bugzilla at redhat.com and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. ________________________________________________________________________ Apache/2.0.46 (Red Hat) Server at bugzilla.redhat.com Port 443 R. -- "It's a fine line between denial and faith. It's much better on my side" From rodd at clarkson.id.au Tue Feb 7 03:15:24 2006 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 07 Feb 2006 14:15:24 +1100 Subject: rawhide report: 20060202 changes In-Reply-To: <1139280329.1654.36.camel@localhost.localdomain> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> <1139262403.24225.5.camel@localhost.localdomain> <95ac75570602061838j1038ffa1nc7e730f0a39dd394@mail.gmail.com> <1139280329.1654.36.camel@localhost.localdomain> Message-ID: <1139282125.3336.7.camel@localhost.localdomain> On Mon, 2006-02-06 at 21:45 -0500, Peter Jones wrote: > On Mon, 2006-02-06 at 18:38 -0800, Alain Mellan wrote: > > I get the same error w/ Beagle. > > > > BTW, upgrading to sqlite 3.3.3-1 still send yum in infinite loop. Had > > to downgrade to 3.3.2. > > You need to update python-sqlite . I've got: [root at localhost /]# rpm -qa | grep sqlite sqlite-devel-3.3.3-1 sqlite2-2.8.17-2 sqlite-3.3.3-1 mono-data-sqlite-1.1.13.2-1 python-sqlite-1.1.6-3 [root at localhost /]# Is there anything more up-to-date? R. -- "It's a fine line between denial and faith. It's much better on my side" From rodd at clarkson.id.au Tue Feb 7 03:17:18 2006 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 07 Feb 2006 14:17:18 +1100 Subject: Internal Server Error at https://bugzilla.redhat.com/ Message-ID: <1139282238.3336.10.camel@localhost.localdomain> I'm seeing: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, bugzilla at redhat.com and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. ________________________________________________________________________ Apache/2.0.46 (Red Hat) Server at bugzilla.redhat.com Port 443 When I try to view https://bugzilla.redhat.com/bugzilla/index.cgi R. -- MOOSE technology po box 6061, north croydon, vic 3136 mobile: 0403 338 731 http://www.moosetech.com.au phone: 03 9726 9457 mailto:rodd at moosetech.com.au fax: 03 9726 9456 "Share your knowledge. It is a way to achieve immortality." -- The Dalai Lama -- "It's a fine line between denial and faith. It's much better on my side" From admin at ramshacklestudios.com Tue Feb 7 07:09:40 2006 From: admin at ramshacklestudios.com (Peter Gordon) Date: Mon, 06 Feb 2006 23:09:40 -0800 Subject: Internal Server Error at https://bugzilla.redhat.com/ In-Reply-To: <1139282238.3336.10.camel@localhost.localdomain> References: <1139282238.3336.10.camel@localhost.localdomain> Message-ID: <1139296180.20248.2.camel@tuxhugger> On Tue, 2006-02-07 at 14:17 +1100, Rodd Clarkson wrote: > I'm seeing: > > Internal Server Error > The server encountered an internal error or misconfiguration and was > unable to complete your request. > [...] It seems to work just fine for me. Perhaps this issue was resolved in the 4 hours or so since you sent this email. :-] -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xDA3634D7 Fingerprint: 0629 F604 3C14 937E F088 E5E9 B3CB 48EC DA36 34D7 -------------- next part -------------- A non-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 Tue Feb 7 07:17:17 2006 From: dax at gurulabs.com (Dax Kelson) Date: Tue, 07 Feb 2006 00:17:17 -0700 Subject: dmraid comments and a warning In-Reply-To: <1139277727.1654.28.camel@localhost.localdomain> References: <1139256516.4440.66.camel@mentorng.gurulabs.com> <1139277727.1654.28.camel@localhost.localdomain> Message-ID: <1139296637.3599.24.camel@mentorng.gurulabs.com> On Mon, 2006-02-06 at 21:02 -0500, Peter Jones wrote: > On Mon, 2006-02-06 at 13:08 -0700, Dax Kelson wrote: > > The standard root=LABEL=/ was used on the kernel command line and what > > happened is that it booted up to one side of the mirror. All the updates > > and new packages (including a new kernel install which modified the > > grub.conf) activity just happened on that one side of the mirror. > > This should be fixed in the current rawhide tree. And now it uses root=/dev/mapper/$DEV ? > > When I rebooted, GRUB read a garbled grub.conf because at that stage ist > > *is* using a 'activated' RAID (via the RAID BIOS support). I couldn't > > boot. > > What do you mean by "garbled" here? From what you've said so far, at > this point you should have two perfectly coherent filesystems -- which > just don't match. Each of them should have a grub.conf, both of which > should be properly formed -- one of them just doesn't match one disk. My guess follows: GRUB always sees the "activated" RAID because of the BIOS RAID driver. When it reads the "grub.conf" it is interleaving pieces of the two (now different) grub.conf files and the result most likely has bogus syntax and content. > > So I booted to the rescue environment, which did the right thing and > > activated the RAID and it even mounted the filesystems. When I went and > > inspected the files though, anything that got touched while it booted to > > the one side of the mirror was trashed. > > So the Really Important Thing about BIOS-based raids is that if you > _ever_ get into the situation where one disk has been written and the > other hasn't, you need to go into your bios and re-sync the disks. And > unfortunately, it's very difficult to automatically detect that you're > in this situation with bios raid. Indeed. > > --Event Two-- > > > > With the benefit of the experience of event one. I did a new install, > > but this time I let Anaconda's disk druid do the "auto setup" thing and > > create a LVM. I figured that LVM using device mapper and dmraid would > > always "do the right thing" in regards to *always* using the activated > > RAID partitions as the PVs. > > What distro were you installing? AFAIK, both this and your previous > configuration should have worked if you installed on a tree after > January 9th or so. That'd mean test2 should have been ok. Jan 14th 2006 rawhide for event one, and jan 14th 2006 initial install with yum updates every couple days for event two. > (I haven't really looked at upgrades yet; hopefully very soon even > though it's not really possible to be "upgrading" from a fc4 dmraid > setup.) I'm not upgrading distros. Just keeping my rawhide install current. > > On bootup I noticed an error flash by something to the effect of "LVM > > ignoring duplicate PV". > > Ok, so this means one of several possible things: > > 1) you're using lvm2 < 2.02.01-1 I installed rawhide on Jan 14th and it has been OK (including updates) until a few days ago. > 2) there's no entry for the dm device in /etc/blkid.tab > 3) for some reason, the priority isn't set on the dm device > in /etc/blkid.tab > 4) there's no dm rules in your initrd See below. > I think that's actually the whole list of practical reasons you'd get to > this point, but it's always possible I've overlooked something. I booted to the rescue environment with a Jan 14th boot.iso and NFS tree. The rescue environment properly activated the dmraid and "pvdisplay" showed "/dev/mapper/nvidia-foo" I looked inside the two initrd files I had: 2.6.15-1.1884 = dm commands inside "init" 2.6.15-1.1889 - no dm commands inside "init" -- dated Feb 4th on my box > One interesting note is that given any of these you should be getting > the same disk mounted each time. Which means there's a good chance that > sda and sdb are both fine, one of them just happens to represent your > machine 3 weeks ago. It installed OK on Jan 14th, and has been successfully booting and using the dmraid until (I think) Feb 4th. > Do you still have this disk set, or have you wiped it and reinstalled > already? If you've got it, I'd like to see /etc/blkid.tab from either > disk (both if possible). Since the / filesystem is in a LVM LV sitting ontop of a dmraid partition PV, it seems non-trivial to force the PV for the LV to change back and both to access the separate files. If you know a way, let me know. When I booted to the rescue environment it activated the dmraid and LVM and I was able to get this /etc/blkid.tab: /dev/dm-1 /dev/dm-5 /dev/dm-2 /dev/dm-4 /dev/sda1 /dev/sda2 /dev/sdb1 /dev/sdb2 /dev/sdb3 /dev/dm-3 /dev/VolGroup00/LogVol01 > > There needs to be more checks in place to prevent booting off of one > > half of the mirror, or at a minimum only allowing a read-only boot on > > one side of the mirror. Dead systems are no fun. Loosing your personal > > data is hell. > > Well, we should have the appropriate checks there at this point -- so > I'd be curious to find out exactly which versions you installed with. > It could be that one of the checks was introduced after you installed, > and the "yum update" process caused it to believe it was *not* a raid > system. As I noted above I discovered the initramfs for 1884 was OK and had dm activation commands but the 1889 initramfs did not. Why the change? I don't know. I've only run yum on the box and haven't touched the LVM or device mapper config myself. > (I haven't been extensively checking to make sure every daily rawhide > would work perfectly as an update from the previous one, just that > they'd install if possible...) > > > This isn't purely a Linux problem. Any operating system using fake RAID1 > > needs to be robust in this regard. I saw a Windows box using 'fake' > > motherboard RAID and the motherboard BIOS got flashed which reset the > > "Use RAID" setting to 'off'. Then Windows booted off of half the RAID. > > That's interesting. It means there's some way to query the BIOS to tell > if it's installed the int13 "raid" hook or not. I wish I knew what that > magic is. Are you sure that's what it means? The motherboard BIOS upgrade turned off RAID and Windows still booted. That wasn't surprising. The writes to one side of the mirror and the subsequent re-activation of the mirror without a proper re-sync in the RAID bios utility caused total foobage. > > The rules are: > > > 1. Don't boot off half of the RAID1 in read-write mode > > Yeah, we definitely still need some fallback stuff here. Excellent. We don't want users complaining that FC5 ate their data. > > 2. If rule 1 is violated, don't ever again boot using the RAID1 > > - If you can abide by rule 2, you can do so indefinitely > > This isn't enforceable in any meaningful way in the software. In fact, > it's scarcely even detectable currently :/ Agreed. It is more of a observation. > > 3. There is no way to recover from a violated rule 1 without > > reinstalling. > > That's not the case -- you can go into the bios and sync from the > "newer" disk to the older one. Or if your bios is total junk, you can > boot some other media and (carefully) re-sync each partition with "dd". This should have occurred to me. Since my RAID bios utility is rather limiting (junk as you say) I overlooked this good suggestion (also noted by Reuben Farrelly) Dax Kelson Guru Labs From hellwolf.misty at gmail.com Tue Feb 7 07:29:05 2006 From: hellwolf.misty at gmail.com (ZC Miao) Date: Tue, 07 Feb 2006 15:29:05 +0800 Subject: where is glxgears and glxinfo? Message-ID: <1139297345.16652.1.camel@cocteau.hellwolf-misty.org> They're no longer in xorg-x11-utils? -- ZC Miao http://hellwolf.cublog.cn/ gpg --keyserver keyserver.veridis.com --recv-key 0x6B174C6F -------------- next part -------------- A non-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 Tue Feb 7 07:36:49 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 06 Feb 2006 23:36:49 -0800 Subject: where is glxgears and glxinfo? In-Reply-To: <1139297345.16652.1.camel@cocteau.hellwolf-misty.org> References: <1139297345.16652.1.camel@cocteau.hellwolf-misty.org> Message-ID: <1139297809.3579.0.camel@ender> On Tue, 2006-02-07 at 15:29 +0800, ZC Miao wrote: > They're no longer in xorg-x11-utils? Mike was going to try and build them on their own, however that didn't work so hot. Last I heard he'll try and get them built in the mesa package. See Mike Harris for details. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at redhat.com Tue Feb 7 08:34:16 2006 From: buildsys at redhat.com (Build System) Date: Tue, 7 Feb 2006 03:34:16 -0500 Subject: rawhide report: 20060207 changes Message-ID: <200602070834.k178YGVA017981@porkchop.devel.redhat.com> New package gnome-python2-desktop The sources for additional PyGNOME Python extension modules for the GNOME desktop. Updated Packages: ORBit2-2.13.3-1 --------------- * Mon Feb 06 2006 Matthias Clasen 2.13.3-1 - Update to 2.13.3 OpenIPMI-1.4.14-18 ------------------ * Mon Feb 06 2006 Phil Knirsch 1.4.14-18 - Updated ipmitool to latest upstream version. - Removed 3 patches for already fixed bugs in latest ipmitool. - Adapted warning message fix for ipmitool for latest version. anaconda-10.91.16-1 ------------------- * Mon Feb 06 2006 Jeremy Katz - 10.91.16-1 - fix writing out instdata for root password, etc (#180310) * Mon Feb 06 2006 Jeremy Katz - 10.91.15-1 - Remove debugging code that broke showing the Xen option on the task screen - More sqlite files (#171232) - Fix traceback for new method pirut depends on - Ensure /dev/root exists (Patrick Mansfield) - Force buttonbar on main screen active in congrats (dcantrel, #179924) - Always pass loglevel (dcantrel) - BR libXt-devel (dcantrel) - Don't try to make /dev/mapper devs (pjones) - More consistency in dev naming for dmraid (pjones) - Start of iscsi patches (Patrick Mansfield) - Fix pre-existing RAID chunksize reading (#178291) autoconf-2.59-6 --------------- * Mon Feb 06 2006 Karsten Hopp 2.59-6 - check for Xlib.h instead of Intrinsic.h to find X11 headers (#176379) bind-30:9.3.2-2.1 ----------------- * Mon Feb 06 2006 Jason Vas Dias - 30:9.3.2-2.1 - Rebuild for new gcc, glibc, glibc-kernheaders * Mon Jan 16 2006 Jason Vas Dias - 30:9.3.2-2 - fix bug 177854: temporary fix for broken kernel-2.6.15-1854+ /proc/net/if_inet6 format * Wed Dec 21 2005 Jason Vas Dias - 30:9.3.2-1 - Upgrade to 9.3.2, released today booty-0.66-1 ------------ * Mon Feb 06 2006 Peter Jones - 0.66-1 - use "mapper/raidnamep0" for partition names instead of "mapper/raidname0" control-center-1:2.13.90-6 -------------------------- * Mon Feb 06 2006 Matthias Clasen - 1:2.13.90-6 - Avoid delays when switching backgrounds * Mon Feb 06 2006 Matthias Clasen - 1:2.13.90-3 - Use the 2.12 background capplet dhcp-11:3.0.3-21.1 ------------------ * Mon Feb 06 2006 Jason Vas Dias - 11:3.0.3-21.1 - Rebuild for new gcc, glibc and glibc-kernheaders eclipse-1:3.1.2-1jpp_4fc ------------------------ * Mon Feb 06 2006 Andrew Overholt 3.1.2-1jpp_4fc - Add an swt-gtk.jar and fix symlink to point to correct jar (rh#180000). - Link against generic libjawt.so (rh#158755). - Re-add patch to use built launcher. firstboot-1.4.3-1 ----------------- * Mon Feb 06 2006 Chris Lumens 1.4.3-1 - Tweak firstboot-tui requires to not require X (#180046). - Wrap left side labels if they're too long. - Remove "Click to Finish" module (#178109). - Try to prevent running in runlevel 3 if we failed in runlevel 5 (#145169). frysk-0.0.1.2006.01.22-0.FC5.1 ------------------------------ * Mon Feb 06 2006 Adam Jocksch 0.0.1.2006.01.22-0.FC5.1 - Bumped version, rebuilt. gcc-4.1.0-0.23 -------------- * Mon Feb 06 2006 Jakub Jelinek 4.1.0-0.23 - update from gcc-4_1-branch (-r110582:110632) - PRs classpath/24618, classpath/25141, classpath/25727, fortran/25046, fortran/26039 - use LOGICAL*1 instead of LOGICAL*4 for Fortran where temporary masks (Roger Sayle) - fix symbol versions in s390 libgcc_s.so.1 - sparc32 and alpha long double fixes - BuildRequires libXt-devel - BuildRequires and Requires glibc-devel >= 2.3.90-35 on arches that are switching long double * Sat Feb 04 2006 Jakub Jelinek 4.1.0-0.22 - fix ia64 debug info patch - fix libjava pthread_create wrapper patch * Sat Feb 04 2006 Jakub Jelinek 4.1.0-0.21 - update from gcc-4_1-branch (-r110433:110582) - PRs c++/25342, c++/25979, fortran/20845, fortran/24266, fortran/24958, fortran/25072, libstdc++/21554, middle-end/24901, middle-end/25977, middle-end/26001, target/25864, target/25926, target/25960 - put ia64 read-only sections that require runtime relocations even in -fno-pic code into .data.rel.ro etc. sections rather than .rodata to avoid DT_TEXTREL binaries (Richard Henderson, PR target/26090) - merge gomp changes from trunk (-r110511:110512 and -r110549:110552) - fix ia64 debug info coverage of epilogues (Alexandre Oliva, PR debug/24444) - export pthread_create from libgcj.so.7 as a wrapper around libpthread.so.0's pthread_create that handles GC (Anthony Green, Tom Tromey) - BC-ABI java lookup fix (Andrew Haley, #179070, #178156) - on sparc64 emit .register %g7,#ignore instead of .register %g7,#scratch to avoid problems with TLS or -fstack-protector - switch to IBM extended format long double by default on ppc and ppc64 - switch to IEEE 754 quad format long double by default on s390, s390x, sparc32 and alpha gedit-1:2.13.90-3 ----------------- * Mon Feb 06 2006 John (J5) Palmieri - 1:2.13.90-3 - Add dependancy on gnome-python2-desktop * Mon Feb 06 2006 Matthias Clasen - 1:2.13.90-2 - Enable python again - Fix multiarch problem glibc-kernheaders-3.0-5 ----------------------- * Mon Feb 06 2006 David Woodhouse 3.0-5 - Add EOWNERDEAD and ENOTRECOVERABLE error codes gnome-icon-theme-2.13.7-1 ------------------------- * Mon Feb 06 2006 Matthias Clasen 2.13.7-1 - Update to 2.13.7 gnome-menus-2.13.5-5 -------------------- * Mon Feb 06 2006 Ray Strode 2.13.5-5 - break infinite loop gnome-python2-2.12.3-1 ---------------------- * Mon Feb 06 2006 John (J5) Palmieri - 2.12.3-1 - Update to 2.12.3 * Tue Dec 20 2005 Jesse Keating - 2.12.1-1.2 - rebuilt for new libgtop * Fri Dec 09 2005 Jesse Keating - 2.12.1-1.1 - rebuilt gnome-python2-extras-2.13.3-3 ----------------------------- * Mon Feb 06 2006 John (J5) Palmieri - 2.13.3-3 - Upload correct tar ball and try again * Mon Feb 06 2006 John (J5) Palmieri - 2.13.3-2 - Bump and rebuild (force-tag fails for this module) * Mon Feb 06 2006 John (J5) Palmieri - 2.13.3-1 - Update to 2.13.3 - Move the gnome-python2-applet gnome-python2-gnomeprint gnome-python2-gtksourceview gnome-python2-libwnck gnome-python2-libgtop2 gnome-python2-nautilus-cd-burner gnome-python2-metacity and gnome-python2-totem subpackages to gnome-python2-desktop because gnome-python-extras was split upstream gnome-utils-1:2.13.91-2 ----------------------- * Mon Feb 06 2006 Matthias Clasen 2.13.91-2 - Fix a gnome-system-log crash gtk2-2.8.11-5 ------------- * Mon Feb 06 2006 Matthias Clasen 2.8.11-5 - Sync render fix with upstream guile-5:1.6.7-5 --------------- * Mon Feb 06 2006 Miroslav Lichvar 5:1.6.7-5 - Avoid marking qthreads library as requiring executable stack (#179274) hwbrowser-0.25-1 ---------------- * Mon Feb 06 2006 Nils Philippsen 0.25 - build and distribute Slovakian translation (#180089) * Thu Dec 22 2005 Nils Philippsen - add sr at Latn translation, distribute Serbian translations (#176134) * Tue Nov 22 2005 Matthias Clasen 0.24 - Remove "Browser" from name, classify as monitor for better menus icon-naming-utils-0.6.7-1 ------------------------- initscripts-8.26-1 ------------------ * Tue Feb 07 2006 Bill Nottingham 8.26-1 - revert "rc.sysinit: don't mount usbfs, libusb no longer uses it" change - add some ugly hacks to make sure net hotplug doesn't run after unclean shutdown (#177795) - don't mount /sys and /proc in rc.sysinit - the initrd already does () - halt: try to unmount tmpfs filesystems before swapoff (#174000, ) intltool-0.34.2-1 ----------------- * Mon Feb 06 2006 Matthias Clasen 0.34.2-1 - Update to 0.34.2 iputils-20020927-34 ------------------- * Mon Feb 06 2006 Radek Vok??l 20020927-34 - ping clean-up, added new ICMP warning messages * Wed Jan 25 2006 Radek Vok??l 20020927-33 - gcc patch, warnings cleaned-up * Tue Dec 13 2005 Radek Vokal 20020927-32 - fix HOPLIMIT option for setsockopt() (#175471) java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_76rh ------------------------------------------ * Mon Feb 06 2006 Thomas Fitzsimmons - 0:1.4.2.0-40jpp_76rh - Test src.zip before extracting its contents. * Mon Feb 06 2006 Thomas Fitzsimmons - 0:1.4.2.0-40jpp_75rh - Use fastjar to extract libgcj sources instead of unzip. * Mon Feb 06 2006 Thomas Fitzsimmons - 0:1.4.2.0-40jpp_74rh - Require gjdoc and libgcj-src packages for build. - Build API documentation. - Add -javadoc package. jpackage-utils-0:1.6.6-1jpp_2rh ------------------------------- * Mon Feb 06 2006 Thomas Fitzsimmons - 0:1.6.6-1jpp_2rh - Add /usr/share/java-1.3.1 and /usr/lib/java-1.3.1 directories. (160327) * Mon Feb 06 2006 Thomas Fitzsimmons - 0:1.6.6-1jpp_1rh - Import jpackage-utils 0:1.6.6-1jpp from jpackage.org. - Add rebuild-security-providers script. - Install security directory in /etc. - Do not provide java-javadoc. - Do not install a dummy package-list file. - Do not take ownership of /usr/share/javadoc/java. * Sun Sep 18 2005 David Walluck 0:1.6.6-1jpp - always define macros kernel-2.6.15-1.1914_FC5 ------------------------ * Mon Feb 06 2006 Dave Jones - 2.6.16rc2-git2 * Mon Feb 06 2006 David Woodhouse - Update to current softmac/bcm43xx code. * Sun Feb 05 2006 Dave Jones - Fix sed failure if /etc/sysconfig/kernel doesn't exist. (#180025) krb5-1.4.3-4 ------------ * Mon Feb 06 2006 Nalin Dahyabhai 1.4.3-4 - give a little bit more information to the user when kinit gets the catch-all I/O error (#180175) * Thu Jan 19 2006 Nalin Dahyabhai 1.4.3-3 - rebuild properly when pthread_mutexattr_setrobust_np() is defined but not declared, such as with recent glibc when _GNU_SOURCE isn't being used * Thu Jan 19 2006 Matthias Clasen 1.4.3-2 - Use full paths in krb5.sh to avoid path lookups libidn-0.6.1-1 -------------- * Mon Feb 06 2006 Florian La Roche - 0.6.1 librsvg2-2.13.92-1 ------------------ * Mon Feb 06 2006 Matthias Clasen 2.13.92-1 - Update to 2.13.92 libtool-1.5.22-2 ---------------- * Mon Feb 06 2006 Karsten Hopp 1.5.22-2 - libtool-ltdl-devel is LGPL (#168075) nautilus-2.13.90-2 ------------------ * Mon Feb 06 2006 Matthias Clasen - 2.13.90-2 - Avoid delays in rendering the background * Tue Jan 31 2006 Matthias Clasen - 2.13.90-1 - Update to 2.13.90 * Tue Jan 17 2006 Matthias Clasen - 2.13.4-1 - Update to 2.13.4 openssh-4.3p1-2 --------------- * Mon Feb 06 2006 Tomas Mraz - 4.3p1-2 - fixed another place where syslog was called in signal handler - pass locale environment variables to server, accept them there (#179851) pango-1.11.4-1 -------------- * Mon Feb 06 2006 Matthias Clasen - 1.11.4-1 - Update to 1.11.4 perl-4:5.8.8-1.2 ---------------- * Mon Feb 06 2006 Jason Vas Dias - 4:5.8.8-1.2 - Rebuild with new gcc, glibc, and glibc-kernheaders * Fri Feb 03 2006 Jason Vas Dias - 4:5.8.8-1.1 - Rebuild with new gcc and glibc * Wed Feb 01 2006 Jason Vas Dias - 4:5.8.8-1 - Upgrade to new upstream release 5.8.8, officially released today planner-0.13-3 -------------- * Mon Feb 06 2006 Caolan McNamara - 0.13-3 - rh#179781# add evolution data server plugin python-pyblock-0.13-1 --------------------- * Mon Feb 06 2006 Peter Jones - 0.13-1 - partition naming/creation/detection fixes - fixes for isw (ICH[4567]R) "groups" sed-4.1.5-1 ----------- * Mon Feb 06 2006 Florian La Roche - 4.1.5 selinux-policy-2.2.11-2 ----------------------- * Mon Feb 06 2006 Dan Walsh 2.2.11-2 - Fix for spamd to use razor port sharutils-4.6.1-1 ----------------- * Mon Feb 06 2006 Florian La Roche - 4.6.1 system-config-samba-1.2.33-1 ---------------------------- * Mon Feb 06 2006 Nils Philippsen - 1.2.33 - fix typo in PAM file (#179937) tar-1.15.1-12 ------------- * Mon Feb 06 2006 Peter Vrabec 1.15.1-12 - fix extracting sparse files to a filesystem like vfat, when ftruncate may fail to grow the size of a file.(#179507) tclx-8.4.0-1 ------------ * Fri Feb 03 2006 David Cantrell - 8.4.0-1 - Upgraded to tclx-8.4.0 - Removed patches that applied to the old build method for tclx - Removed Tcl and Tk doc archives tomboy-0.3.5-1 -------------- * Mon Feb 06 2006 Christopher Aillon - 0.3.5-1 - Tomboy 0.3.5 udev-078-9 ---------- * Mon Feb 06 2006 Harald Hoyer - 078-9 - closed fd leak (bug #179980) unzip-5.52-2 ------------ * Mon Feb 06 2006 Ivana Varekova 5.52-2 - fix bug 180078 - unzip -l causing error - fix CVE-2005-4667 - unzip long file name buffer overflow * Thu Dec 22 2005 Ivana Varekova 5.52-1 - update to 5.52 * Fri Dec 09 2005 Jesse Keating - rebuilt xorg-x11-server-1.0.1-2 ----------------------- * Sun Feb 05 2006 Mike A. Harris 1.0.1-2 - Added xorg-x11-server-1.0.1-fbpict-fix-rounding.patch from CVS HEAD. - Added xorg-x11-server-1.0.1-SEGV-on-null-interface.patch which prevents a SEGV on null interfaces (#174279,178986) zsh-4.2.5-1.2.1 --------------- * Tue Feb 07 2006 Jesse Keating - 4.2.5-1.2.1 - rebuilt for new gcc4.1 snapshot and glibc changes Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 emacspeak - 23.0-1.noarch requires /usr/bin/tcl gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 Broken deps for ia64 ---------------------------------------------------------- emacspeak - 23.0-1.noarch requires /usr/bin/tcl rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- ccs-devel - 1.0.2-3.1.ppc requires ccs = 0:1.0.2-3.1 emacspeak - 23.0-1.noarch requires /usr/bin/tcl gulm - 1.0.4-2.FC5.1.ppc requires ccs Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi emacspeak - 23.0-1.noarch requires /usr/bin/tcl gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 Broken deps for s390 ---------------------------------------------------------- emacspeak - 23.0-1.noarch requires /usr/bin/tcl systemtap - 0.5.4-2.s390 requires kernel >= 0:2.6.9-11 Broken deps for s390x ---------------------------------------------------------- emacspeak - 23.0-1.noarch requires /usr/bin/tcl libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) systemtap - 0.5.4-2.s390x requires kernel >= 0:2.6.9-11 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 emacspeak - 23.0-1.noarch requires /usr/bin/tcl gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 From che666 at gmail.com Tue Feb 7 08:41:29 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Tue, 7 Feb 2006 09:41:29 +0100 Subject: where is glxgears and glxinfo? In-Reply-To: <1139297809.3579.0.camel@ender> References: <1139297345.16652.1.camel@cocteau.hellwolf-misty.org> <1139297809.3579.0.camel@ender> Message-ID: 2006/2/7, Jesse Keating : > On Tue, 2006-02-07 at 15:29 +0800, ZC Miao wrote: > > They're no longer in xorg-x11-utils? > > Mike was going to try and build them on their own, however that didn't > work so hot. Last I heard he'll try and get them built in the mesa > package. See Mike Harris for details. > > -- > Jesse Keating RHCE (geek.j2solutions.net) > Fedora Legacy Team (www.fedoralegacy.org) > GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2 (GNU/Linux) > > iD8DBQBD6E4R4v2HLvE71NURAsaiAJ9GIyy9t0Roi8v/06mF2SO09kPTuwCZAQe7 > HF8nTINQ9FMEayA3BYuLzbQ= > =/WAz > -----END PGP SIGNATURE----- > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > glewinfo from the gl extension wrangler could replace glxinfo just fine. http://glew.sourceforge.net/ regards, Rudolf Kastl p.s. would be nice to see glew in extras anyways... its pretty nice ;) From emeric.maschino at jouy.inra.fr Tue Feb 7 09:02:37 2006 From: emeric.maschino at jouy.inra.fr (Emeric Maschino) Date: Tue, 07 Feb 2006 10:02:37 +0100 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <20060204012809.GP24295@devserv.devel.redhat.com> References: <1139006387.2652.29.camel@bree.local.net> <43E3FF02.1060803@argo.co.il> <20060204012809.GP24295@devserv.devel.redhat.com> Message-ID: <1139302958.5067.4.camel@localhost.localdomain> > > >Although I hate to do it, it looks like we're going to have to slip > > >Fedora Core 5 test3 by a week. There is an ABI change in the gcc/glibc > > >stack that requires a rebuild of the entire distribution. > > > > > > > > Can you elaborate on this ABI change? > 3) many binaries on ia64 were having text relocations, which is bad > from security POV Does this mean that the forthcoming gcc/glibc packages will address this issue and that the execmod checks can be enabled again in the IA-64 kernel? From jakub at redhat.com Tue Feb 7 09:05:27 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 7 Feb 2006 04:05:27 -0500 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <1139302958.5067.4.camel@localhost.localdomain> References: <1139006387.2652.29.camel@bree.local.net> <43E3FF02.1060803@argo.co.il> <20060204012809.GP24295@devserv.devel.redhat.com> <1139302958.5067.4.camel@localhost.localdomain> Message-ID: <20060207090526.GR24295@devserv.devel.redhat.com> On Tue, Feb 07, 2006 at 10:02:37AM +0100, Emeric Maschino wrote: > > > >Although I hate to do it, it looks like we're going to have to slip > > > >Fedora Core 5 test3 by a week. There is an ABI change in the gcc/glibc > > > >stack that requires a rebuild of the entire distribution. > > > > > > > > > > > Can you elaborate on this ABI change? > > > > > 3) many binaries on ia64 were having text relocations, which is bad > > from security POV > > > > Does this mean that the forthcoming gcc/glibc packages will address this > issue and that the execmod checks can be enabled again in the IA-64 > kernel? Yes, but it would be better to wait until all packages are rebuilt ;). Jakub From alexl at redhat.com Tue Feb 7 09:18:02 2006 From: alexl at redhat.com (Alexander Larsson) Date: Tue, 07 Feb 2006 10:18:02 +0100 Subject: rawhide report: 20060202 changes In-Reply-To: <1139262856.13559.64.camel@bree.local.net> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> <1139262403.24225.5.camel@localhost.localdomain> <1139262856.13559.64.camel@bree.local.net> Message-ID: <1139303882.30912.4.camel@greebo> On Mon, 2006-02-06 at 16:54 -0500, Jeremy Katz wrote: > On Tue, 2006-02-07 at 08:46 +1100, Rodd Clarkson wrote: > > Trying to run f-spot I get: > [snip] > > Do I bugzilla? > > This is due to the move from sqlite2 -> sqlite3 changing the db format > which f-spot doesn't handle that well. Probably worth a bugzilla, > although as we haven't "shipped" a sqlite2 based version, it might not > be the highest priority thing to handle Its quite possible to manually convert ~/.gnome2/f-spot/photos.db from sqlite2 to sqlite3 format by dump/restore with "sqlite" and "sqlite3" commands. I did this to test it, but I don't have the exact command lines around anymore. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a short-sighted chivalrous Green Beret who must take medication to keep him sane. She's a high-kicking renegade opera singer in the wrong place at the wrong time. They fight crime! From emeric.maschino at jouy.inra.fr Tue Feb 7 09:16:16 2006 From: emeric.maschino at jouy.inra.fr (Emeric Maschino) Date: Tue, 07 Feb 2006 10:16:16 +0100 Subject: Request for testers: Video hardware autodetection In-Reply-To: <43E4A50E.5070209@mharris.ca> References: <43E4A50E.5070209@mharris.ca> Message-ID: <1139303776.5067.11.camel@localhost.localdomain> Hi Mike and the list, With a completely up-to-date Rawhide system, my ATI FireGL X1 (device ID 0x1002/0x4e47) is set to use the vesa driver rather than the radeon one. This is on an Itanium 2 system (IA-64 architecture) if relevant. Have a nice day, ?meric From kzak at redhat.com Tue Feb 7 09:22:31 2006 From: kzak at redhat.com (Karel Zak) Date: Tue, 07 Feb 2006 10:22:31 +0100 Subject: sudo env_reset in FC5 Message-ID: <1139304152.14148.61.camel@petra> Hi, I'd like to enable the env_reset option in the sudoers config file by default in FC5: Defaults env_reset Defaults env_keep = "COLORS DISPLAY EDITOR HOSTNAME HISTSIZE INPUTRC KDEDIR \ LESSOPEN LS_COLORS MAIL PS1 PS2 QTDIR SSH_ASKPASS USERNAME \ LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION \ LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC \ LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS \ _XKB_CHARSET" Why? The reason is CVE-2005-4158, CVE-2006-0151 and probably a lot of same bugs in future. Comments & suggestion? Karel -- Karel Zak From emeric.maschino at jouy.inra.fr Tue Feb 7 10:03:06 2006 From: emeric.maschino at jouy.inra.fr (Emeric Maschino) Date: Tue, 07 Feb 2006 11:03:06 +0100 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <20060207090526.GR24295@devserv.devel.redhat.com> References: <1139006387.2652.29.camel@bree.local.net> <43E3FF02.1060803@argo.co.il> <20060204012809.GP24295@devserv.devel.redhat.com> <1139302958.5067.4.camel@localhost.localdomain> <20060207090526.GR24295@devserv.devel.redhat.com> Message-ID: <1139306586.5067.23.camel@localhost.localdomain> > > > > > > > 3) many binaries on ia64 were having text relocations, which is bad > > > from security POV > > > > > > > > Does this mean that the forthcoming gcc/glibc packages will address this > > issue and that the execmod checks can be enabled again in the IA-64 > > kernel? > > Yes, but it would be better to wait until all packages are rebuilt ;). Sure ;-) Will there be a message on the Fedora devel list to inform people that all the packages have been rebuilt or is there an other way to know it (some of the rpm query options maybe)? ?meric From andy at warmcat.com Tue Feb 7 10:11:12 2006 From: andy at warmcat.com (Andy Green) Date: Tue, 07 Feb 2006 10:11:12 +0000 Subject: OLPC + Fedora = ? Message-ID: <43E87240.9010204@warmcat.com> Hi folks - There doesn't seem to be a place to talk about the RH OLPC project yet. I mailed the olpc at redhat.com address last week but didn't hear anything yet. It seems that Fedora and the OLPC development effort would have a lot in common. I wanted to make some suggestions which are a little radical but hopefully can make some interesting discussion before things are set in stone. My core starting assumption is that the box cannot be made for the price suggested and that triage will be needed. Therefore the software must get ahead of the game by assuming a weaker processor and half the flash. Please understand though that these are just suggestions for thinking about, not demands, complaints, etc. Hardware Seems hard to believe that with such a low price point, AMD will deliver optimal pricing and that the target CPU throughput is not excessive with x86. Isn't it better for the longer term to only weakly couple the concept of the cheap laptop to a processor arch? Isn't it better if it's more of a virtual specification that, say, random Chinese companies can compete with each other to provide at the lowest possible price, without encumbered CPU designs even like Arm? It's great to tout it around Large American Corporations, but it would be a big win if the final specification was buildable by anyone. - AMD x86 -> OpenRISC 1200 (Has working GNU toolchain) http://www.opencores.org/projects.cgi/web/or1k/openrisc_1200 - ??? expensive patented video --> Opencores VGA/LCD controller http://www.opencores.org/projects.cgi/web/vga_lcd/overview - Sound -> Cheap SPI codec, eg, http://focus.ti.com/docs/prod/folders/print/tlv320aic23b.html or AC97 interface to external mixer http://www.opencores.org/projects.cgi/web/ac97/overview Software - Linux 2.6 with hardware-optimized .config - glibc -> uclibc http://www.uclibc.org/ or newlib http://sources.redhat.com/newlib/ - coreutils + bash + a ton of other stuff -> busybox http://www.busybox.net - ssh -> dropbear (http://matt.ucc.asn.au/dropbear/dropbear.html ) - apache -> lighttpd (http://lighttpd.net ) - firefox -> Opera? Used in Nokia 770... thought it was OSS now but couldn't find link on site. - various media players / codecs -> Ogg Vorbis + Theora only What will the new modular X do faced with linking to something other than glibc? What about Gnome? - Although I am a KDE man, Gnome really impressed me for the first time on the Nokia 770. The KISS vibe actually worked in that context. The 770 would be a good model for what's needed generally in fact (http://maemo.org , http://maemo.org/platform/docs/maemo_exec_whitepaper.html ) - Ext3 root filesystem -> JFFS2 NAND root filesystem - Grub -> u-boot (http://sourceforge.net/cvs/?group_id=65938 ) .. can pull a bzImage out of JFFS2 directly in <100K Well I'm sure these ideas and more are already floating around, it would be cool if these can be dual-purposed into a uber lightweight "Fedora Beanie" version. Ultimately a lot of package specfiles will have to have the configure options revisited anyway... -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From naoki at valuecommerce.com Tue Feb 7 10:19:41 2006 From: naoki at valuecommerce.com (Naoki) Date: Tue, 07 Feb 2006 19:19:41 +0900 Subject: rawhide report: 20060207 changes In-Reply-To: <200602070834.k178YGVA017981@porkchop.devel.redhat.com> References: <200602070834.k178YGVA017981@porkchop.devel.redhat.com> Message-ID: <1139307581.2603.0.camel@dragon.sys.intra> > nautilus-2.13.90-2 > ------------------ > * Mon Feb 06 2006 Matthias Clasen - 2.13.90-2 > - Avoid delays in rendering the background Sweet, just tested this and it's much better! From jkeating at redhat.com Tue Feb 7 10:25:19 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 07 Feb 2006 02:25:19 -0800 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <1139306586.5067.23.camel@localhost.localdomain> References: <1139006387.2652.29.camel@bree.local.net> <43E3FF02.1060803@argo.co.il> <20060204012809.GP24295@devserv.devel.redhat.com> <1139302958.5067.4.camel@localhost.localdomain> <20060207090526.GR24295@devserv.devel.redhat.com> <1139306586.5067.23.camel@localhost.localdomain> Message-ID: <1139307919.3579.4.camel@ender> On Tue, 2006-02-07 at 11:03 +0100, Emeric Maschino wrote: > Sure ;-) > > Will there be a message on the Fedora devel list to inform people that > all the packages have been rebuilt or is there an other way to know it > (some of the rpm query options maybe)? I'll be reporting to the list the progress of the mass rebuild. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From redhat at olen.net Tue Feb 7 10:33:19 2006 From: redhat at olen.net (Ola Thoresen) Date: Tue, 7 Feb 2006 10:33:19 +0000 (UTC) Subject: Fedora Core 5 Test 3 Slip References: <1139006387.2652.29.camel@bree.local.net> <1139280881.3462.0.camel@cosima.et.endace.com> Message-ID: 2006-02-07 Michael J Knox wrote > > My laptop, a Toshiba A10, goes to sleep, but never returns. Probably > file a bug report tonight. > My "noname" - 3-4 years old - laptop goes to sleep, and wakes up. It takes a good 5-10 minutes before it actually awakes, but it will give me a password dialog (from the screensaver) eventually. There are two problems however: I. The mousepad is completely useless after it returns. The cursor moves without any control all over the screen. II. After 2-3 minutes of working ok (except from the mouse problem) my wireless card dies. It spews out messages about TX buffer being full and not being able to load the firmware, before it stops transmitting and receiving any data. The strange thing is that i actually works fine for a few minutes before this happens, so it seems like something is trying to fix a nonexisiting problem - and leaving the wireless card (prism54) in an unusable state. Rgds. Ola Thoresen From rc040203 at freenet.de Tue Feb 7 10:43:53 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 07 Feb 2006 11:43:53 +0100 Subject: rawhide report: 20060207 changes In-Reply-To: <200602070834.k178YGVA017981@porkchop.devel.redhat.com> References: <200602070834.k178YGVA017981@porkchop.devel.redhat.com> Message-ID: <1139309034.1084.53.camel@mccallum.corsepiu.local> On Tue, 2006-02-07 at 03:34 -0500, Build System wrote: > New package gnome-python2-desktop > autoconf-2.59-6 > --------------- > * Mon Feb 06 2006 Karsten Hopp 2.59-6 > - check for Xlib.h instead of Intrinsic.h to find X11 headers > (#176379) Not necessarily a good idea, because this renders FC generated configure scripts unnecessarily incompatible to FSF autoconf generated ones. Furthermore, the whole idea of checking for "X11 headers" is arguable, because the concept of common directories for "X11-includes/libraries" doesn't apply anymore with modular X anymore. Instead, we now have a "set of X11 devel packages", which just "happen to be installed to a common prefix". I would eagerly plea to revert this change. Ralf From kzak at redhat.com Tue Feb 7 11:20:59 2006 From: kzak at redhat.com (Karel Zak) Date: Tue, 07 Feb 2006 12:20:59 +0100 Subject: sudo env_reset in FC5 In-Reply-To: <1139304152.14148.61.camel@petra> References: <1139304152.14148.61.camel@petra> Message-ID: <1139311259.20809.3.camel@petra> On Tue, 2006-02-07 at 10:22 +0100, Karel Zak wrote: > Hi, > > I'd like to enable the env_reset option in the sudoers config file by > default in FC5: > > > Defaults env_reset > Defaults env_keep = "COLORS DISPLAY EDITOR HOSTNAME HISTSIZE INPUTRC KDEDIR \ > LESSOPEN LS_COLORS MAIL PS1 PS2 QTDIR SSH_ASKPASS USERNAME \ > LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION \ > LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC \ > LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS \ > _XKB_CHARSET" > Note: maybe all envs with a path to something executable should be removed from the list (it means LESSOPEN, SSH_ASKPASS and EDITOR). Karel -- Karel Zak From mharris at mharris.ca Tue Feb 7 11:30:36 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Tue, 07 Feb 2006 06:30:36 -0500 Subject: where is glxgears and glxinfo? In-Reply-To: <1139297345.16652.1.camel@cocteau.hellwolf-misty.org> References: <1139297345.16652.1.camel@cocteau.hellwolf-misty.org> Message-ID: <43E884DC.1030503@mharris.ca> ZC Miao wrote: > They're no longer in xorg-x11-utils? They never were in xorg-x11-utils. ;o) yum install glx-utils in about 2 days. It's a subpackage of mesa now, since MesaDemos uses the same undesireable buildsystem as Mesa does, and the source is quite married to Mesa. It turns out that it only increases the size of the src.rpm by 800Kb, which isn't too bad, and the build time increases only by a few seconds, so it isn't as bad as I expected. Probably better off having it this way than in a seperate SRPM in hindsight. It'll take a few days for it to hit rawhide public servers tho. As a slight teaser.... * Tue Feb 7 2006 Mike A. Harris 6.4.2-2 - Added new "glx-utils" subpackage with glxgears and glxinfo (#173510) - Added mesa-6.4.2-dprintf-to-debugprintf-for-bug180122.patch to workaround a Mesa namespace conflict with GNU_SOURCE (#180122) - Added mesa-6.4.2-xorg-server-uses-bad-datatypes-breaking-AMD64-fdo5835.patch as an attempt to fix bugs (#176976,176414,fdo#5835) - Enabled inclusion of the *EXPERIMENTAL UNSUPPORTED* r300 DRI driver on x86, x86_64, and ppc architectures, however the 2D Radeon driver will soon be modified to require the user to manually turn experimental DRI support on with Option "dri" in xorg.conf to test it out and report all X bugs that occur while using it directly to X.Org bugzilla. (#179712) * Sat Feb 4 2006 Mike A. Harris 6.4.2-1 - Updated to Mesa 6.4.2 - Use "libGLU.so.1.3.0604*" glob in file manifest, to avoid having to update it each upstream release. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From hughsient at gmail.com Tue Feb 7 11:33:45 2006 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 07 Feb 2006 11:33:45 +0000 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <1139280881.3462.0.camel@cosima.et.endace.com> References: <1139006387.2652.29.camel@bree.local.net> <1139014200.2863.65.camel@yoda.loki.me> <43E48DDD.4060508@vip.hr> <200602041255.23869.lamont@gurulabs.com> <43E5095E.3060804@mharris.ca> <43E6763A.8050509@uindy.edu> <43E7186E.7050307@redhat.com> <1139243683.3188.14.camel@yoda.loki.me> <1139279542.1654.34.camel@localhost.localdomain> <1139279983.2697.16.camel@ender> <1139280881.3462.0.camel@cosima.et.endace.com> Message-ID: <1139312025.3427.2.camel@localhost.localdomain> On Tue, 2006-02-07 at 15:54 +1300, Michael J Knox wrote: > On Mon, 2006-02-06 at 18:39 -0800, Jesse Keating wrote: > > On Mon, 2006-02-06 at 21:32 -0500, Peter Jones wrote: > > > > > > Hrm. Does it actually go back to sleep, or just turn the screen off? > > > > Back to sleep. I see dmesg saying "Entering memsleep" or something like > > that. The moon lights up on my laptop too. > > > > > Can you ping it? > > > > I haven't tried to yet, but I'm pretty sure I can't. > > > > > What video card do you have? > > > > 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] > > My laptop, a Toshiba A10, goes to sleep, but never returns. Probably > file a bug report tonight. My Toshiba A10 seems to suspend fine now on FC4 - using the latest updates-released kernel, hal 0.5.6 and pm-utils 0.06. You can get the latter two from http://gnome-power.sourceforge.net/data/utopia.repo Richard. From emeric.maschino at jouy.inra.fr Tue Feb 7 11:57:05 2006 From: emeric.maschino at jouy.inra.fr (Emeric Maschino) Date: Tue, 07 Feb 2006 12:57:05 +0100 Subject: where is glxgears and glxinfo? In-Reply-To: <43E884DC.1030503@mharris.ca> References: <1139297345.16652.1.camel@cocteau.hellwolf-misty.org> <43E884DC.1030503@mharris.ca> Message-ID: <1139313425.5067.32.camel@localhost.localdomain> Mike, > - Enabled inclusion of the *EXPERIMENTAL UNSUPPORTED* r300 DRI driver on > x86, x86_64, and ppc architectures, however the 2D Radeon driver will > soon be modified to require the user to manually turn experimental > DRI support on with Option "dri" in xorg.conf to test it out and > report all X bugs that occur while using it directly to X.Org > bugzilla. (#179712) Would it be also possible to enable *EXPERIMENTAL UNSUPPORTED* (as you say) r300 support on the ia64 architecture too so that I can start testing? ?meric From bart.vanbrabant at zoeloelip.be Tue Feb 7 12:18:41 2006 From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant) Date: Tue, 07 Feb 2006 13:18:41 +0100 Subject: beagle in rawhide Message-ID: <43E89021.9000106@zoeloelip.be> Hello, There are some problems when installing fedora from rawhide and beagle. I installed fedora two days ago. I also installed beagle and there are some problems. The evolution-sharp package isn't installed when installing beagle, is this a packaging problem? beagle also needs extended attributes, ext3 supports this but user_xattr isn't added to partition where the /home directory is placed. This should be enabled. g, Bart -- Bart Vanbrabant PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From mharris at mharris.ca Tue Feb 7 12:22:09 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Tue, 07 Feb 2006 07:22:09 -0500 Subject: rawhide report: 20060207 changes In-Reply-To: <1139309034.1084.53.camel@mccallum.corsepiu.local> References: <200602070834.k178YGVA017981@porkchop.devel.redhat.com> <1139309034.1084.53.camel@mccallum.corsepiu.local> Message-ID: <43E890F1.9060903@mharris.ca> Ralf Corsepius wrote: > On Tue, 2006-02-07 at 03:34 -0500, Build System wrote: > >>New package gnome-python2-desktop > > >>autoconf-2.59-6 >>--------------- >>* Mon Feb 06 2006 Karsten Hopp 2.59-6 >>- check for Xlib.h instead of Intrinsic.h to find X11 headers >> (#176379) > > > Not necessarily a good idea, because this renders FC generated configure > scripts unnecessarily incompatible to FSF autoconf generated ones. > > Furthermore, the whole idea of checking for "X11 headers" is arguable, > because the concept of common directories for "X11-includes/libraries" > doesn't apply anymore with modular X anymore. Instead, we now have a > "set of X11 devel packages", which just "happen to be installed to a > common prefix". > > I would eagerly plea to revert this change. I'd go one step further, and consider the change to be a bug. All of the X libraries install pkgconfig *.pc files in X11R7.0 as a standard. Various other things like the SDK, font utils, etc. also install pkgconfig files. All packages in the distribution which need to know where the X headers are installed, or need to know anything that is supplied via the pkgconfig files, should use pkg-config to find it. If a package wishes to retain build time compatibility with X11R6 et al. it could use fallbacks if the pkg-config files aren't present, however from here on out, using pkgconfig is the very highly recommended way to detect the X libraries and other bits and pieces. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From igorm5 at vip.hr Tue Feb 7 12:23:53 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Tue, 07 Feb 2006 13:23:53 +0100 Subject: rawhide report: 20060202 changes In-Reply-To: <1139282117.3336.5.camel@localhost.localdomain> References: <200602021553.k12FrHK7003484@porkchop.devel.redhat.com> <1139262403.24225.5.camel@localhost.localdomain> <43E7C972.2010508@vip.hr> <1139282117.3336.5.camel@localhost.localdomain> Message-ID: <43E89159.8000504@vip.hr> Rodd Clarkson ka?e: > On Mon, 2006-02-06 at 23:10 +0100, Igor Jagec wrote: >>>Do I bugzilla? >>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179983 > Hmmm, tried this and got: Just remove ~/.gnome2/f-spot/photos.db file and that's it. It helped me thoe. Cheers! -- Igor Jagec From reuben-fedora-devel at reub.net Tue Feb 7 12:30:07 2006 From: reuben-fedora-devel at reub.net (Reuben Farrelly) Date: Wed, 08 Feb 2006 01:30:07 +1300 Subject: rawhide report: 20060207 changes In-Reply-To: <200602070834.k178YGVA017981@porkchop.devel.redhat.com> References: <200602070834.k178YGVA017981@porkchop.devel.redhat.com> Message-ID: <43E892CF.8030402@reub.net> Just a heads up... On 7/02/2006 9:34 p.m., Build System wrote: > initscripts-8.26-1 > ------------------ > * Tue Feb 07 2006 Bill Nottingham 8.26-1 > - revert "rc.sysinit: don't mount usbfs, libusb no longer uses it" change > - add some ugly hacks to make sure net hotplug doesn't run after unclean > shutdown (#177795) > - don't mount /sys and /proc in rc.sysinit - the initrd already does > () That change breaks any system where there is no initrd (like mine where I build what I need into the kernel itself). If you're running a custom built kernel you'll get a pretty nasty series of failure messages if you don't have an initrd where these mounts are done since the system is pretty must screwed if there is no /proc and /sys. Perhaps what would be more appropriate is initscripts to test to see if those mounts exist (ie have been mounted already) and if so then continue, if not then mount them then continue. > - halt: try to unmount tmpfs filesystems before swapoff (#174000, > ) [I was also further hosed when the Fedora kernel wouldn't boot, it hung mounting something in fstab, but I'll look more into that]. reuben From bressers at redhat.com Tue Feb 7 12:47:06 2006 From: bressers at redhat.com (Josh Bressers) Date: Tue, 07 Feb 2006 07:47:06 -0500 Subject: sudo env_reset in FC5 In-Reply-To: <1139311259.20809.3.camel@petra> References: <1139304152.14148.61.camel@petra> <1139311259.20809.3.camel@petra> Message-ID: <20060207124706.5C600B4001@evolution.bress.net> > On Tue, 2006-02-07 at 10:22 +0100, Karel Zak wrote: > > Hi, > > > > I'd like to enable the env_reset option in the sudoers config file by > > default in FC5: > > > > > > Defaults env_reset > > Defaults env_keep = "COLORS DISPLAY EDITOR HOSTNAME HISTSIZE INPUTRC KDEDIR \ > > LESSOPEN LS_COLORS MAIL PS1 PS2 QTDIR SSH_ASKPASS USERNAME \ > > LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION \ > > LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC \ > > LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS \ > > _XKB_CHARSET" > > > > Note: maybe all envs with a path to something executable should be > removed from the list (it means LESSOPEN, SSH_ASKPASS and EDITOR). You'll be making my day if you do this Karl. I would suggest starting with a minimal env_keep whitelist. We can always expand it, and as long as there is a release note about it, it will only surprise the people who don't read the release notes. We can expand it in the future as needed. Thanks. -- JB From rdieter at math.unl.edu Tue Feb 7 12:58:06 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 07 Feb 2006 06:58:06 -0600 Subject: digikam(extras) conflicts with koffice(devel) In-Reply-To: References: Message-ID: <43E8995E.5020603@math.unl.edu> Neal Becker wrote: > Transaction Check Error: file /usr/share/mimelnk/image/x-raw.desktop from > install of koffice-core-1.4.90-2.fc5 conflicts with file from package > digikam-0.8.1-1.fc5 http://bugzilla.redhat.com/bugzilla/179754 kdegraphics includes that mimetype too. Looks like the best solution is to move it to kdelibs so everyone can share/use it. -- Rex From ellson at research.att.com Tue Feb 7 13:03:49 2006 From: ellson at research.att.com (John Ellson) Date: Tue, 07 Feb 2006 08:03:49 -0500 Subject: rawhide report: 20060207 changes In-Reply-To: <1139309034.1084.53.camel@mccallum.corsepiu.local> References: <200602070834.k178YGVA017981@porkchop.devel.redhat.com> <1139309034.1084.53.camel@mccallum.corsepiu.local> Message-ID: <43E89AB5.1060904@research.att.com> Ralf Corsepius wrote: > On Tue, 2006-02-07 at 03:34 -0500, Build System wrote: > >> New package gnome-python2-desktop >> > > >> autoconf-2.59-6 >> --------------- >> * Mon Feb 06 2006 Karsten Hopp 2.59-6 >> - check for Xlib.h instead of Intrinsic.h to find X11 headers >> (#176379) >> > > Not necessarily a good idea, because this renders FC generated configure > scripts unnecessarily incompatible to FSF autoconf generated ones. > > Furthermore, the whole idea of checking for "X11 headers" is arguable, > because the concept of common directories for "X11-includes/libraries" > doesn't apply anymore with modular X anymore. Instead, we now have a > "set of X11 devel packages", which just "happen to be installed to a > common prefix". > > I would eagerly plea to revert this change. > > Ralf > > > > The AC_PATH_XTRA macro doesn't work today. Is that a result of this change? John From rdieter at math.unl.edu Tue Feb 7 13:09:31 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 07 Feb 2006 07:09:31 -0600 Subject: digikam(extras) conflicts with koffice(devel) In-Reply-To: <43E8995E.5020603@math.unl.edu> References: <43E8995E.5020603@math.unl.edu> Message-ID: <43E89C0B.2000409@math.unl.edu> Rex Dieter wrote: > Neal Becker wrote: > >> Transaction Check Error: file /usr/share/mimelnk/image/x-raw.desktop >> from >> install of koffice-core-1.4.90-2.fc5 conflicts with file from package >> digikam-0.8.1-1.fc5 > See "digikam/kdegraphics conflicts" > http://bugzilla.redhat.com/bugzilla/179754 And: "koffice digikam/kdegraphics conflicts" http://bugzilla.redhat.com/bugzilla/180335 -- Rex From nicolas.mailhot at laposte.net Tue Feb 7 12:51:06 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 7 Feb 2006 13:51:06 +0100 (CET) Subject: rawhide report: 20060207 changes In-Reply-To: <43E890F1.9060903@mharris.ca> References: <200602070834.k178YGVA017981@porkchop.devel.redhat.com> <1139309034.1084.53.camel@mccallum.corsepiu.local> <43E890F1.9060903@mharris.ca> Message-ID: <33374.192.54.193.25.1139316666.squirrel@rousalka.dyndns.org> Le Mar 7 f?vrier 2006 13:22, Mike A. Harris a ?crit : > Ralf Corsepius wrote: >> On Tue, 2006-02-07 at 03:34 -0500, Build System wrote: >> >>>New package gnome-python2-desktop >> >> >>>autoconf-2.59-6 >>>--------------- >>>* Mon Feb 06 2006 Karsten Hopp 2.59-6 >>>- check for Xlib.h instead of Intrinsic.h to find X11 headers >>> (#176379) >> >> >> Not necessarily a good idea, because this renders FC generated configure >> scripts unnecessarily incompatible to FSF autoconf generated ones. >> >> Furthermore, the whole idea of checking for "X11 headers" is arguable, >> because the concept of common directories for "X11-includes/libraries" >> doesn't apply anymore with modular X anymore. Instead, we now have a >> "set of X11 devel packages", which just "happen to be installed to a >> common prefix". >> >> I would eagerly plea to revert this change. > > I'd go one step further, and consider the change to be a bug. All > of the X libraries install pkgconfig *.pc files in X11R7.0 as a > standard. Various other things like the SDK, font utils, etc. > also install pkgconfig files. > > All packages in the distribution which need to know where the X > headers are installed, or need to know anything that is supplied > via the pkgconfig files, should use pkg-config to find it. Also it seems where papering over autoconf bugs. autoconf used to test for one header to find a monolithic X system. Changing the BuildRequires to make the test succeed does not mean the package is fixed, since autoconf is now detecting one part of X, and not the full sheebang it expects. -- Nicolas Mailhot From cmadams at hiwaay.net Tue Feb 7 13:42:45 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 7 Feb 2006 07:42:45 -0600 Subject: where is glxgears and glxinfo? In-Reply-To: <43E884DC.1030503@mharris.ca> References: <1139297345.16652.1.camel@cocteau.hellwolf-misty.org> <43E884DC.1030503@mharris.ca> Message-ID: <20060207134245.GB945651@hiwaay.net> Once upon a time, Mike A. Harris said: > As a slight teaser.... > > > * Tue Feb 7 2006 Mike A. Harris 6.4.2-2 Any update on the SELinux vs. libGL vs. execstack issue? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From dcbw at redhat.com Tue Feb 7 13:45:07 2006 From: dcbw at redhat.com (Dan Williams) Date: Tue, 07 Feb 2006 08:45:07 -0500 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <1139256234.3188.32.camel@yoda.loki.me> References: <20060206170343.96873.qmail@web51514.mail.yahoo.com> <1139245971.3188.18.camel@yoda.loki.me> <1139248650.2970.58.camel@lt16585.campus.dmacc.edu> <1139256234.3188.32.camel@yoda.loki.me> Message-ID: <1139319908.3795.3.camel@localhost.localdomain> > On Mon, 2006-02-06 at 11:57 -0600, Jeffrey C. Ollie wrote: > > > > I know that yum/mock/plague doesn't quite fit the bill as a beehive > > replacement, but it would be nice if RedHat could work with the > > community to extend yum/mock/plague rather than re-inventing the wheel. > > > > I know that one thing that plague could use is a way to easily switch > > the plague client between two or more plague servers. This falls under the definition of "sort of" easy... Setting PLAGUE_CLIENT_CONFIG to the path of whatever plague client config file you'd like to use should do the trick. Possible enhancement would be to have /etc/plague-client.d and ~/.plague-client.d directories, stick plague files in there, and then have some sort of short switch to select which one you want. Kind of like yum --enable-repo. So in this case I'd have one xterm for Fedora Extras with the extras plague config, and another xterm for Legacy (or whatever) with another plague config listed in the env var above. Dan From mailinglists at erwinrol.com Tue Feb 7 13:47:57 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Tue, 07 Feb 2006 14:47:57 +0100 Subject: trying to install rawhide In-Reply-To: <1139279970.3100.4.camel@bree.local.net> References: <1139276618.8135.31.camel@xpc.home.erwinrol.com> <1139279970.3100.4.camel@bree.local.net> Message-ID: <1139320077.8135.44.camel@xpc.home.erwinrol.com> On Mon, 2006-02-06 at 21:39 -0500, Jeremy Katz wrote: > On Tue, 2006-02-07 at 02:43 +0100, Erwin Rol wrote: > > Yeah, somehow the us layout became azerty instead... there's nothing in > the logs to really help in figuring out why. The x86_64 tree is fine. > So, we're going to see if it goes away tomorrow (in which case, it could > just be something weird on a specific build machine) With todays rawhide i have a normal qwerty keyboard again. Last thing on tty3 is; Running anaconda script /usr/bin/anaconda Now I also get an error message on tty1. Keep in mind I am running in text mode, cause i don't really trust my radeon FireMV 2400 (quad head card to work out of the box). And it is an old 800MHz Athlon TB. The error is now as follows; Running anaconda, The Fedora Core Installer - please wait Could not find platform independent libraries in Consider setting $PYTHONHOME to [:] 'import site' failed; use -v for traceback Traceback (most recent call last): File "/usr/bin/anaconda", line 28, in ? import sys, os ImportError: No module named os install exited abnormally > We're testing and fixing things as fast as we can -- unfortunately, > we're not perfect yet :-) Nobody expects you to be perfect, as long as Fedora is ;-P - Erwin From dcbw at redhat.com Tue Feb 7 13:52:49 2006 From: dcbw at redhat.com (Dan Williams) Date: Tue, 07 Feb 2006 08:52:49 -0500 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <43E7B9FC.4010901@mharris.ca> References: <20060206170343.96873.qmail@web51514.mail.yahoo.com> <1139245971.3188.18.camel@yoda.loki.me> <1139248650.2970.58.camel@lt16585.campus.dmacc.edu> <43E7B9FC.4010901@mharris.ca> Message-ID: <1139320369.3795.11.camel@localhost.localdomain> On Mon, 2006-02-06 at 16:05 -0500, Mike A. Harris wrote: > usage internally by individuals, and our next generation buildsystem > is aparently based on mock/plague. What more exactly are you looking Technically just mock. There are some specific architectural differences, not to mention different target audiences, for the nextgen internal stuff versus plague. For example, plague is meant to be distributed so that the builders and server don't have to be run by the same organization. This means that RPMs and SRPMs are transferred with HTTP, because you can't rely on fast local shared storage. In a centralized buildsystem model, that's just nuts because you'll almost always have fast centralized storage. The user model is also quite simplistic, while in an enterprise you'd usually hook this stuff up to a directory or other authentication means. Plague isn't meant as an enterprise build system, though it could be expanded to fill that role. If it did, it would end up like Bugzilla; way to complicated to install over a weekend, and completely in need of a babysitter 6 out of 7 nights a week. Dan From mailinglists at erwinrol.com Tue Feb 7 14:03:48 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Tue, 07 Feb 2006 15:03:48 +0100 Subject: trying to install rawhide In-Reply-To: <1139320077.8135.44.camel@xpc.home.erwinrol.com> References: <1139276618.8135.31.camel@xpc.home.erwinrol.com> <1139279970.3100.4.camel@bree.local.net> <1139320077.8135.44.camel@xpc.home.erwinrol.com> Message-ID: <1139321028.8135.52.camel@xpc.home.erwinrol.com> When i run the installer in "normal" non text mode or in rescue mode i get the following error: Running anaconda, the Fedora Core rescue mode - please wait... Traceback (most recent call last): File "/usr/bin/anaconda", line 377, in ? import dispatch File "/usr/lib/anaconda/dispatch.py", line 34, in ? from bootloader import writeBootloader, bootloaderSetupChoices File "/usr/lib/anaconda/bootloader.py", line 33, in ? from booty import * File "/usr/lib/booty/booty.py", line 28, in ? from bootloaderInfo import * File "/usr/lib/booty/bootloaderInfo.py", line 713 if grubTarget[-2] == 'p' or ^ SyntaxError: invalid syntax install exited abnormally I will try to whipe the old grub and partition table with knoppix and retry the install. - Erwin From jeff at ocjtech.us Tue Feb 7 14:18:55 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 07 Feb 2006 08:18:55 -0600 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <43E7B9FC.4010901@mharris.ca> References: <20060206170343.96873.qmail@web51514.mail.yahoo.com> <1139245971.3188.18.camel@yoda.loki.me> <1139248650.2970.58.camel@lt16585.campus.dmacc.edu> <43E7B9FC.4010901@mharris.ca> Message-ID: <1139321936.2884.20.camel@lt16585.campus.dmacc.edu> On Mon, 2006-02-06 at 16:05 -0500, Mike A. Harris wrote: > Jeffrey C. Ollie wrote: > > On Mon, 2006-02-06 at 09:12 -0800, Jesse Keating wrote: > > > >>On Mon, 2006-02-06 at 09:03 -0800, Steve G wrote: > >> > >>>Out of curiosity, when the rebuild occurs...does the script use an alphabetical > >>>listing of the packages from a to z. Or does the script try to build the packages > >>>in a somewhat ordered fashion from no dependencies (attr, zlib, bzip, etc) to > >>>more complicated packages that have many dependencies (mkinitrd, pam, slang, > >>>etc.) > >> > >>Mostly just an a to z thing. The way our current build system works, > >>every package is installed into the build root, so at this point we're > >>pretty assured that all build reqs will be met. This is not optimal for > >>many reasons, and a replacement build system is being developed that > >>fixes this. > > > > > > I know that yum/mock/plague doesn't quite fit the bill as a beehive > > replacement, but it would be nice if RedHat could work with the > > community to extend yum/mock/plague rather than re-inventing the wheel. > > > > I know that one thing that plague could use is a way to easily switch > > the plague client between two or more plague servers. > > s/RedHat/Red Hat/ > > Would it make that much of a difference though, or would people still > say the same thing? I think even if Red Hat devoted 2 or more > employees working full time on mock/plague that people would still > say the same thing. Why do I think that? Well for starters, Red Hat > has contributed quite a lot to plague already from what I understand. > I don't know the level of contribution to mock, but it gets heavy > usage internally by individuals, and our next generation buildsystem > is aparently based on mock/plague. What more exactly are you looking > for? For mock, the only thing that would be nice to have is a way to cache a "clean" build root. Having to set up a fresh build root every time you build a package is a major time waste. For plague, the first thing that would be nice would be some documentation. I know that's asking a lot, but hey this is a wish list, so I'm gonna aim high. I don't know how many people outside of the Fedora admin crew have tried to set up a full plague buildsystem but it took me some time and reading source code to get a system up and running. The second thing would be a better X.509 certificate management utility. Since plague uses TLS and X.509 certificates for encryption/authentication it would be nice to have something better for managing certificates than the openssl command line. > I suppose Red Hat could in theory hire every single person who > has contributed to either project... ;o) Hey, I'm available! And I've contributed one (itty bitty eentsy weentsy) fix to mock. :). > But then there would > be conspiracy theories about something else right? ;o) There is no Red Hat cabal. :) 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 rc040203 at freenet.de Tue Feb 7 14:24:53 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 07 Feb 2006 15:24:53 +0100 Subject: rawhide report: 20060207 changes In-Reply-To: <43E89AB5.1060904@research.att.com> References: <200602070834.k178YGVA017981@porkchop.devel.redhat.com> <1139309034.1084.53.camel@mccallum.corsepiu.local> <43E89AB5.1060904@research.att.com> Message-ID: <1139322293.1084.58.camel@mccallum.corsepiu.local> On Tue, 2006-02-07 at 08:03 -0500, John Ellson wrote: > Ralf Corsepius wrote: > > On Tue, 2006-02-07 at 03:34 -0500, Build System wrote: > > > >> New package gnome-python2-desktop > >> > > > > > >> autoconf-2.59-6 > >> --------------- > >> * Mon Feb 06 2006 Karsten Hopp 2.59-6 > >> - check for Xlib.h instead of Intrinsic.h to find X11 headers > >> (#176379) > >> > > > > Not necessarily a good idea, because this renders FC generated configure > > scripts unnecessarily incompatible to FSF autoconf generated ones. > > > > Furthermore, the whole idea of checking for "X11 headers" is arguable, > > because the concept of common directories for "X11-includes/libraries" > > doesn't apply anymore with modular X anymore. Instead, we now have a > > "set of X11 devel packages", which just "happen to be installed to a > > common prefix". > > > > I would eagerly plea to revert this change. > > > > Ralf > > > > > > > > > The AC_PATH_XTRA macro doesn't work today. Is that a result of this change? If you expect AC_PATH_XTRA to pickup libXt and friends (libICE, libXm etc. - it did until now), probably yes. Ralf From jwboyer at jdub.homelinux.org Tue Feb 7 13:38:52 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 7 Feb 2006 08:38:52 -0500 (EST) Subject: beagle in rawhide In-Reply-To: <43E89021.9000106@zoeloelip.be> References: <43E89021.9000106@zoeloelip.be> Message-ID: <64990.129.42.161.36.1139319532.squirrel@jdub.homelinux.org> > Hello, > beagle also needs extended attributes, ext3 supports this but user_xattr > isn't added to partition where the /home directory is placed. This > should be enabled. That's not quite true. Beagle recommends using user_xattr, but I believe there is a sqlite db backup if those aren't enabled. josh From jeff at ocjtech.us Tue Feb 7 14:43:40 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 07 Feb 2006 08:43:40 -0600 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <1139320369.3795.11.camel@localhost.localdomain> References: <20060206170343.96873.qmail@web51514.mail.yahoo.com> <1139245971.3188.18.camel@yoda.loki.me> <1139248650.2970.58.camel@lt16585.campus.dmacc.edu> <43E7B9FC.4010901@mharris.ca> <1139320369.3795.11.camel@localhost.localdomain> Message-ID: <1139323420.2884.44.camel@lt16585.campus.dmacc.edu> On Tue, 2006-02-07 at 08:52 -0500, Dan Williams wrote: > On Mon, 2006-02-06 at 16:05 -0500, Mike A. Harris wrote: > > usage internally by individuals, and our next generation buildsystem > > is aparently based on mock/plague. What more exactly are you looking > > Technically just mock. There are some specific architectural > differences, not to mention different target audiences, for the nextgen > internal stuff versus plague. > For example, plague is meant to be > distributed so that the builders and server don't have to be run by the > same organization. This means that RPMs and SRPMs are transferred with > HTTP, because you can't rely on fast local shared storage. Hmmm, perhaps that's the way that plague works now. If the buildsystem-ng server and the builder communicated using URLs, rather than directly passing RPMs and SRPMs around, you could use "file://" URLs to refer to centralized storage or "http://" URLs to refer to remote servers. A little bit of smarts would then allow the builders and servers to avoid downloading via HTTP if they didn't have to. That would let buildsystem-ng handle both cases. > The user model is also quite > simplistic, while in an enterprise you'd usually hook this stuff up to a > directory or other authentication means. I'd agree that the *authorization* model of plague is simplistic, but the use of X.509 certificates for *authentication* I would think is quite good. > Plague isn't meant as an enterprise build system, though it could be > expanded to fill that role. If it did, it would end up like Bugzilla; > way to complicated to install over a weekend, and completely in need of > a babysitter 6 out of 7 nights a week. To me, systems like that usually indicate a failure in the planning and design stage. Now, I'm not saying that Red Hat should take the plague code as the base for the new build system. We should take the lessons learned from plague and beehive and build a new, better build system that will serve both the needs of Red Hat/Fedora Core and Fedora Extras (although not necessarily on the same hardware). 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 clumens at redhat.com Tue Feb 7 14:52:21 2006 From: clumens at redhat.com (Chris Lumens) Date: Tue, 7 Feb 2006 09:52:21 -0500 Subject: trying to install rawhide In-Reply-To: <1139321028.8135.52.camel@xpc.home.erwinrol.com> References: <1139276618.8135.31.camel@xpc.home.erwinrol.com> <1139279970.3100.4.camel@bree.local.net> <1139320077.8135.44.camel@xpc.home.erwinrol.com> <1139321028.8135.52.camel@xpc.home.erwinrol.com> Message-ID: <20060207145221.GB23868@exeter.boston.redhat.com> > Running anaconda, the Fedora Core rescue mode - please wait... > Traceback (most recent call last): > File "/usr/bin/anaconda", line 377, in ? > import dispatch > File "/usr/lib/anaconda/dispatch.py", line 34, in ? > from bootloader import writeBootloader, bootloaderSetupChoices > File "/usr/lib/anaconda/bootloader.py", line 33, in ? > from booty import * > File "/usr/lib/booty/booty.py", line 28, in ? > from bootloaderInfo import * > File "/usr/lib/booty/bootloaderInfo.py", line 713 > if grubTarget[-2] == 'p' or > ^ > SyntaxError: invalid syntax > install exited abnormally Ah, this is just a syntax error in booty. I'll build a new one and this should be fixed up in tomorrow's tree. - Chris From dravet at hotmail.com Tue Feb 7 15:12:49 2006 From: dravet at hotmail.com (Jason Dravet) Date: Tue, 07 Feb 2006 09:12:49 -0600 Subject: Request for testers: Video hardware autodetection Message-ID: I would love to test this new autodection setup. However when I run system-config-display it crashes. I opened a bugzilla about this over two months ago and no work has been done to fix this problem. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174686 Thanks, Jason From clumens at redhat.com Tue Feb 7 15:39:50 2006 From: clumens at redhat.com (Chris Lumens) Date: Tue, 7 Feb 2006 10:39:50 -0500 Subject: trying to install rawhide In-Reply-To: <1139320077.8135.44.camel@xpc.home.erwinrol.com> References: <1139276618.8135.31.camel@xpc.home.erwinrol.com> <1139279970.3100.4.camel@bree.local.net> <1139320077.8135.44.camel@xpc.home.erwinrol.com> Message-ID: <20060207153949.GA7276@exeter.boston.redhat.com> > The error is now as follows; > Running anaconda, The Fedora Core Installer - please wait > Could not find platform independent libraries in > Consider setting $PYTHONHOME to [:] > 'import site' failed; use -v for traceback > Traceback (most recent call last): > File "/usr/bin/anaconda", line 28, in ? > import sys, os > ImportError: No module named os > install exited abnormally This is related to the booty fix - the image building script failed because of the booty import problem, so minstg2.img didn't have most of the python modules in it. This should therefore be fixed up again tomorrow. - Chris From katzj at redhat.com Tue Feb 7 15:46:41 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 07 Feb 2006 10:46:41 -0500 Subject: rawhide report: 20060207 changes In-Reply-To: <1139309034.1084.53.camel@mccallum.corsepiu.local> References: <200602070834.k178YGVA017981@porkchop.devel.redhat.com> <1139309034.1084.53.camel@mccallum.corsepiu.local> Message-ID: <1139327201.20462.0.camel@orodruin.boston.redhat.com> On Tue, 2006-02-07 at 11:43 +0100, Ralf Corsepius wrote: > On Tue, 2006-02-07 at 03:34 -0500, Build System wrote: > > New package gnome-python2-desktop > > autoconf-2.59-6 > > --------------- > > * Mon Feb 06 2006 Karsten Hopp 2.59-6 > > - check for Xlib.h instead of Intrinsic.h to find X11 headers > > (#176379) > > Not necessarily a good idea, because this renders FC generated configure > scripts unnecessarily incompatible to FSF autoconf generated ones. The patch is also applied to upstream autoconf. See http://lists.gnu.org/archive/html/bug-autoconf/2005-09/msg00024.html Jeremy From brilong at cisco.com Tue Feb 7 16:12:56 2006 From: brilong at cisco.com (Brian Long) Date: Tue, 07 Feb 2006 11:12:56 -0500 Subject: mock + ccache? (was Re: nothing from buildsys?) In-Reply-To: <200602031214.26645.lamont@gurulabs.com> References: <43E1E0BE.2080908@adslpipe.co.uk> <20060203164535.GA20256@osiris.silug.org> <1138992276.5160.2.camel@ignacio.lan> <200602031214.26645.lamont@gurulabs.com> Message-ID: <1139328776.4527.31.camel@brilong-lnx> On Fri, 2006-02-03 at 12:14 -0700, Lamont R. Peterson wrote: > On Friday 03 February 2006 11:44am, Ignacio Vazquez-Abrams wrote: > > On Fri, 2006-02-03 at 10:45 -0600, Steven Pritchard wrote: > > > That reminds me... Has anyone ever tried to tie mock and ccache > > > together somehow? It seems like that would speed up repeated build > > > attempts noticably. > > > > It is potentially possible, but the problem is that ccache has in the > > past caused build issues from time to time for various people outside of > > mock. I dare not think what chaos it could wreak in a semi-automated > > buildsystem. distcc *might* be a better choice, once it's ready. > > Instead of distcc, how about considering icecream? Interesting. http://wiki.kde.org/tiki-index.php?page=icecream We use Teambuilder (mentioned in the IceCream wiki) for distributed builds. It's a commercial product from Trolltech. /Brian/ -- Brian Long | | | IT Data Center Systems | .|||. .|||. Cisco Linux Developer | ..:|||||||:...:|||||||:.. Phone: (919) 392-7363 | C i s c o S y s t e m s From che666 at gmail.com Tue Feb 7 16:16:51 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Tue, 7 Feb 2006 17:16:51 +0100 Subject: mock + ccache? (was Re: nothing from buildsys?) In-Reply-To: <1139328776.4527.31.camel@brilong-lnx> References: <43E1E0BE.2080908@adslpipe.co.uk> <20060203164535.GA20256@osiris.silug.org> <1138992276.5160.2.camel@ignacio.lan> <200602031214.26645.lamont@gurulabs.com> <1139328776.4527.31.camel@brilong-lnx> Message-ID: 2006/2/7, Brian Long : > On Fri, 2006-02-03 at 12:14 -0700, Lamont R. Peterson wrote: > > On Friday 03 February 2006 11:44am, Ignacio Vazquez-Abrams wrote: > > > On Fri, 2006-02-03 at 10:45 -0600, Steven Pritchard wrote: > > > > That reminds me... Has anyone ever tried to tie mock and ccache > > > > together somehow? It seems like that would speed up repeated build > > > > attempts noticably. > > > > > > It is potentially possible, but the problem is that ccache has in the > > > past caused build issues from time to time for various people outside of > > > mock. I dare not think what chaos it could wreak in a semi-automated > > > buildsystem. distcc *might* be a better choice, once it's ready. > > > > Instead of distcc, how about considering icecream? > > Interesting. http://wiki.kde.org/tiki-index.php?page=icecream > > We use Teambuilder (mentioned in the IceCream wiki) for distributed > builds. It's a commercial product from Trolltech. > > /Brian/ > -- > Brian Long | | | > IT Data Center Systems | .|||. .|||. > Cisco Linux Developer | ..:|||||||:...:|||||||:.. > Phone: (919) 392-7363 | C i s c o S y s t e m s > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Hello well my opinion is that there should be config hooks to easily hook in components like ccache distcc and/or icecream. regards, Rudolf Kastl From rc040203 at freenet.de Tue Feb 7 16:35:49 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 07 Feb 2006 17:35:49 +0100 Subject: rawhide report: 20060207 changes In-Reply-To: <1139327201.20462.0.camel@orodruin.boston.redhat.com> References: <200602070834.k178YGVA017981@porkchop.devel.redhat.com> <1139309034.1084.53.camel@mccallum.corsepiu.local> <1139327201.20462.0.camel@orodruin.boston.redhat.com> Message-ID: <1139330149.1084.70.camel@mccallum.corsepiu.local> On Tue, 2006-02-07 at 10:46 -0500, Jeremy Katz wrote: > On Tue, 2006-02-07 at 11:43 +0100, Ralf Corsepius wrote: > > On Tue, 2006-02-07 at 03:34 -0500, Build System wrote: > > > New package gnome-python2-desktop > > > autoconf-2.59-6 > > > --------------- > > > * Mon Feb 06 2006 Karsten Hopp 2.59-6 > > > - check for Xlib.h instead of Intrinsic.h to find X11 headers > > > (#176379) > > > > Not necessarily a good idea, because this renders FC generated configure > > scripts unnecessarily incompatible to FSF autoconf generated ones. > > The patch is also applied to upstream autoconf. See > http://lists.gnu.org/archive/html/bug-autoconf/2005-09/msg00024.html Upstream == autoconf-2.60 == untested, unreleased, potentially buggy. However, what upstream does, doesn't matter in this case: You have hacked a autoconf-2.59 in a proprietary way, FC5-autoconf generated scripts will be non-reproducible on other platforms. As an isolated FC5 specific hack, this step is not helpful - If upstream introduces it to autoconf-2.60, this change would be helpful. Also, this patch is meaningless/non-functional when using vanilla autoconf-2.59 generated configure scripts on FC5, nor does it fix configure scripts having been generated by ancient autoconf version. Ralf From brilong at cisco.com Tue Feb 7 16:46:46 2006 From: brilong at cisco.com (Brian Long) Date: Tue, 07 Feb 2006 11:46:46 -0500 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <43E6763A.8050509@uindy.edu> References: <1139006387.2652.29.camel@bree.local.net> <1139014200.2863.65.camel@yoda.loki.me> <43E48DDD.4060508@vip.hr> <200602041255.23869.lamont@gurulabs.com> <43E5095E.3060804@mharris.ca> <43E6763A.8050509@uindy.edu> Message-ID: <1139330806.4527.41.camel@brilong-lnx> On Sun, 2006-02-05 at 17:03 -0500, D Canfield wrote: > Mike A. Harris wrote: > > > > I think our 6 month cycle plan remains, but will likely vary depending > > on various factors. I'd like to see it be a 9 month cycle that can > > vary earlier or later though, but that's just my personal opinion. I > > dunno who else would agree with me on that. ;) > > > > Perhaps this is just my own experience and impressions, but through the > RHL releases and even as recently as the first couple of FC releases, I > was always eagerly awaiting each new release because of various great > improvements that made the system more generally usable. As tired as I > would get of constantly rebuilding my machine, I would install most of > the test releases just because I wanted those features that badly. With > FC 3 & 4, my "appetite" for new releases has slowed down significantly, > and the only reason I look for betas nowadays is usually support for > newer hardware. In fact, the only two things I'm eager for in FC5 are a > working suspend on my thinkpad, and evolution syncing on my Treo > (neither of which looks is looking too promising anymore). > > The point of all that is to say that I think as FC and Linux/OSS mature, > there will be less demand for a steady stream of updates, and a 9-12 > month release cycle would probably be quite acceptable. In fact, if > things go the direction they seem to be, most people would probably > prefer a longer-lived Core infrastructure, and look more to Extras for > faster-moving updates to day-to-day apps. > > Just my perception. DC, I would agree with you. Inside my company, many folks have switched to self-supported Ubuntu or Gentoo because of the rolling-upgrade functionality where they don't have to re-install the entire OS to get the latest features. It would be really cool if Jeremy and the rest of the installer team worked to make rolling upgrades between releases of Fedora (and RHEL) possible with standard yum commands instead of requiring a new install/upgrade procedure each time. Internally, we don't support Anaconda's "upgrade" mode because it's had issues over the years and we don't want to clean up the mess :) This means we have to tell folks to reinstall their OS between major versions of RHEL and the same holds true between FC2 -> FC3 -> FC4. After hearing all these complaints internally, I'd say it would be absolutely _awesome_ if I were able to upgrade from FC5 -> FC6 without running Anaconda. Has any serious thought gone into this? Is it a high, medium or low priority for future development or is it not even on the radar at this point? /Brian/ -- Brian Long | | | IT Data Center Systems | .|||. .|||. Cisco Linux Developer | ..:|||||||:...:|||||||:.. Phone: (919) 392-7363 | C i s c o S y s t e m s From jreiser at BitWagon.com Tue Feb 7 16:51:03 2006 From: jreiser at BitWagon.com (John Reiser) Date: Tue, 07 Feb 2006 08:51:03 -0800 Subject: signal handling: virtualization, kernel-to-user info leak Message-ID: <43E8CFF7.50704@BitWagon.com> My user-mode virtualization of signal handling stopped working in FC5. I figured out why; the details, and a kernel patch, are in: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180351 The dwarf2 unwind info in the vDSO for rt_sigframe, as well as the kernel rt_sigreturn() itself, takes a shortcut by referencing the struct ucontext directly, instead of via the puc pointer. This means that a thread kill to cancel a pthread_cond_wait causes a SIGSEGV when unwinding through the virtualized rt_sigframe. (The virtualized frame copies the four scalars {pretcode, sig, pinfo, puc} while leaving the full structs behind.) Returning from virtualized signal handler also gets a SIGSEGV because the kernel uses the ucontext that it "knows" is there, instead of accessing it indirectly through the pointer puc. Somewhat related, the kernel leaks ["garbage"] data from the kernel stack when placing the struct siginfo onto the user stack. In arch/i386/kernel/signal.c, subroutine do_signal() declares an on-stack automatic local siginfo_t info; The routine fills in portions without clearing the whole struct, then copies the entire struct onto the user stack. It's not cheap to clear (the internal union is 116 bytes long, and uses only about 28 bytes or so), but isn't this an information security issue? -- From pmatilai at laiskiainen.org Tue Feb 7 17:00:13 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 07 Feb 2006 19:00:13 +0200 Subject: mock + ccache? (was Re: nothing from buildsys?) In-Reply-To: <20060203164535.GA20256@osiris.silug.org> References: <43E1E0BE.2080908@adslpipe.co.uk> <5256d0b0602020239s3aa68266p37346bfc4d493c12@mail.gmail.com> <43E1F427.3050701@reub.net> <43E32D5A.5050907@mharris.ca> <20060203164535.GA20256@osiris.silug.org> Message-ID: <1139331613.27273.17.camel@weasel.turre.laiskiainen.org> On Fri, 2006-02-03 at 10:45 -0600, Steven Pritchard wrote: > On Fri, Feb 03, 2006 at 05:15:54AM -0500, Mike A. Harris wrote: > > If you've got a 1.5Ghz CPU or faster, and install "ccache" from Fedora > > Extras, your machine will build pretty much any package faster than > > our buildsystem. ;o) > > That reminds me... Has anyone ever tried to tie mock and ccache > together somehow? It seems like that would speed up repeated build > attempts noticably. At least with mach it works nicely, just install ccache into the chroot and it'll get used. I don't remember if mock recreates the chroot from scratch each time you build something - if not it should be just a matter of installing ccache in the root (via buildgroup or manually), otherwise it'll get more tricky. - Panu - From katzj at redhat.com Tue Feb 7 17:01:01 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 07 Feb 2006 12:01:01 -0500 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <1139330806.4527.41.camel@brilong-lnx> References: <1139006387.2652.29.camel@bree.local.net> <1139014200.2863.65.camel@yoda.loki.me> <43E48DDD.4060508@vip.hr> <200602041255.23869.lamont@gurulabs.com> <43E5095E.3060804@mharris.ca> <43E6763A.8050509@uindy.edu> <1139330806.4527.41.camel@brilong-lnx> Message-ID: <1139331662.2907.6.camel@bree.local.net> On Tue, 2006-02-07 at 11:46 -0500, Brian Long wrote: > I would agree with you. Inside my company, many folks have switched to > self-supported Ubuntu or Gentoo because of the rolling-upgrade > functionality where they don't have to re-install the entire OS to get > the latest features. It would be really cool if Jeremy and the rest of > the installer team worked to make rolling upgrades between releases of > Fedora (and RHEL) possible with standard yum commands instead of > requiring a new install/upgrade procedure each time. The amount of pain involved here ends up being astronomical for some types of changes. Think about things like all new tools for 2.6, static /dev -> udev, what to do with all sorts of things moving out from under you from /usr/X11R6 -> /usr. Things do mostly end up working (I do an update to rawhide on my laptop anywhere between daily and weekly -- and it hasn't had an install since I got it about two years ago), but it's hardly the sort of thing that's really supportable. > Internally, we don't support Anaconda's "upgrade" mode because it's had > issues over the years and we don't want to clean up the mess :) This > means we have to tell folks to reinstall their OS between major versions > of RHEL and the same holds true between FC2 -> FC3 -> FC4. So, you're saying that instead you want to support upgrades where you could be running on top of anything with any sort of processes running? It's far saner to support doing upgrades in a known and consistent environment (ie, the installer stage2) as opposed to your running system. Jeremy From chitlesh at fedoraproject.org Tue Feb 7 17:04:32 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 7 Feb 2006 18:04:32 +0100 Subject: rawhide report: 20060207 changes In-Reply-To: <200602070834.k178YGVA017981@porkchop.devel.redhat.com> References: <200602070834.k178YGVA017981@porkchop.devel.redhat.com> Message-ID: <13dbfe4f0602070904k535e4eaci5a074f01cbd96c1d@mail.gmail.com> > anaconda-10.91.16-1 > ------------------- > * Mon Feb 06 2006 Jeremy Katz - 10.91.16-1 > - fix writing out instdata for root password, etc (#180310) > > * Mon Feb 06 2006 Jeremy Katz - 10.91.15-1 > - Remove debugging code that broke showing the Xen option on the task screen > - More sqlite files (#171232) > - Fix traceback for new method pirut depends on > - Ensure /dev/root exists (Patrick Mansfield) > - Force buttonbar on main screen active in congrats (dcantrel, #179924) > - Always pass loglevel (dcantrel) > - BR libXt-devel (dcantrel) > - Don't try to make /dev/mapper devs (pjones) > - More consistency in dev naming for dmraid (pjones) > - Start of iscsi patches (Patrick Mansfield) > - Fix pre-existing RAID chunksize reading (#178291) Hello, Ive just updated to anaconda-10.91.16-1. import dispatch is failing ! [root at goorah FC5T2]# kadischi /tmp/FC5T2/ /tmp/FC5kde.iso Starting kadischi... Parsing command line arguments Checking UID Using buildstamp file /etc/kadischi/buildstamp. Product path set to Fedora. Now we are going to try to validate your repository (for now, only http, ftp and local repositories can be checked) Path /tmp/FC5T2 exists. OK Path /tmp/FC5T2/Fedora exists. OK Path /tmp/FC5T2/Fedora/base exists. OK Path /tmp/FC5T2/Fedora/RPMS exists. OK Repository seems to be OK. Checking required packages Looking for config file Loadnig config file options *** running anaconda *** Traceback (most recent call last): File "/usr/sbin/anaconda", line 377, in ? import dispatch File "/usr/lib/anaconda/dispatch.py", line 34, in ? from bootloader import writeBootloader, bootloaderSetupChoices File "/usr/lib/anaconda/bootloader.py", line 33, in ? from booty import * File "/usr/lib/booty/booty.py", line 28, in ? from bootloaderInfo import * File "/usr/lib/booty/bootloaderInfo.py", line 713 if grubTarget[-2] == 'p' or ^ SyntaxError: invalid syntax *** Fatal error: anaconda returned non zero (256) exit code. Aborting execution. Cleaning up temporary files... Done. From chitlesh at fedoraproject.org Tue Feb 7 17:29:44 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 7 Feb 2006 18:29:44 +0100 Subject: rawhide report: 20060207 changes In-Reply-To: <13dbfe4f0602070904k535e4eaci5a074f01cbd96c1d@mail.gmail.com> References: <200602070834.k178YGVA017981@porkchop.devel.redhat.com> <13dbfe4f0602070904k535e4eaci5a074f01cbd96c1d@mail.gmail.com> Message-ID: <13dbfe4f0602070929j56d8cb7ge6ae9bcbb67c0865@mail.gmail.com> > File "/usr/lib/booty/bootloaderInfo.py", line 713 > if grubTarget[-2] == 'p' or > ^ > SyntaxError: invalid syntax if ( grubTarget[-2] == 'p' or (grubTarget[-2].isdigit() and grubTarget[-3] == 'p') ) : ive added ( and ) and am having the network config first afterwards on clicking on next seems that anaconda is operational afterwards with the network config as first screen. -- http://clunixchit.blogspot.com From notting at redhat.com Tue Feb 7 17:35:44 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 7 Feb 2006 12:35:44 -0500 Subject: rawhide report: 20060207 changes In-Reply-To: <13dbfe4f0602070904k535e4eaci5a074f01cbd96c1d@mail.gmail.com> References: <200602070834.k178YGVA017981@porkchop.devel.redhat.com> <13dbfe4f0602070904k535e4eaci5a074f01cbd96c1d@mail.gmail.com> Message-ID: <20060207173544.GB2182@devserv.devel.redhat.com> Chitlesh GOORAH (chitlesh at fedoraproject.org) said: > Traceback (most recent call last): > File "/usr/sbin/anaconda", line 377, in ? > import dispatch > File "/usr/lib/anaconda/dispatch.py", line 34, in ? > from bootloader import writeBootloader, bootloaderSetupChoices > File "/usr/lib/anaconda/bootloader.py", line 33, in ? > from booty import * > File "/usr/lib/booty/booty.py", line 28, in ? > from bootloaderInfo import * > File "/usr/lib/booty/bootloaderInfo.py", line 713 > if grubTarget[-2] == 'p' or > ^ > SyntaxError: invalid syntax booty bug, fixed in 0.67-1, should be out tomorrw. Bill From toshio at tiki-lounge.com Tue Feb 7 17:41:13 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 07 Feb 2006 09:41:13 -0800 Subject: rawhide report: 20060207 changes In-Reply-To: <43E890F1.9060903@mharris.ca> References: <200602070834.k178YGVA017981@porkchop.devel.redhat.com> <1139309034.1084.53.camel@mccallum.corsepiu.local> <43E890F1.9060903@mharris.ca> Message-ID: <1139334073.4897.16.camel@localhost> On Tue, 2006-02-07 at 07:22 -0500, Mike A. Harris wrote: > If a package wishes to retain build time compatibility with > X11R6 et al. it could use fallbacks if the pkg-config files > aren't present, however from here on out, using pkgconfig > is the very highly recommended way to detect the X libraries > and other bits and pieces. > Where should this be implemented? Should AC_PATH_X/XTRA be changed to attempt to use pkgconfig as a first choice and then use AC_PATH_X if it isn't found? (I don't know how autoconf deals with dependencies on optional m4 macros but for now I'm supposing this is possible) Or does every package using AC_PATH_X need to create the logic for using pkg-config with optional fallbacks to X11R6 behavior and then try to push those changes upstream (using autoconf/autoconf-patches until the changes are accepted and released.) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From clumens at redhat.com Tue Feb 7 18:25:07 2006 From: clumens at redhat.com (Chris Lumens) Date: Tue, 7 Feb 2006 13:25:07 -0500 Subject: rawhide report: 20060207 changes In-Reply-To: <13dbfe4f0602070929j56d8cb7ge6ae9bcbb67c0865@mail.gmail.com> References: <200602070834.k178YGVA017981@porkchop.devel.redhat.com> <13dbfe4f0602070904k535e4eaci5a074f01cbd96c1d@mail.gmail.com> <13dbfe4f0602070929j56d8cb7ge6ae9bcbb67c0865@mail.gmail.com> Message-ID: <20060207182506.GA7561@exeter.boston.redhat.com> > if ( grubTarget[-2] == 'p' or > (grubTarget[-2].isdigit() and grubTarget[-3] == 'p') ) : > ive added ( and ) and am having the network config first afterwards on > clicking on next seems that anaconda is operational afterwards with > the network config as first screen. Fixed in anaconda CVS. We'll most likely roll out a new package tonight to fix it. Note that this just affects the order of the steps, nothing else. - Chris From brugolsky at telemetry-investments.com Tue Feb 7 19:19:30 2006 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Tue, 7 Feb 2006 14:19:30 -0500 Subject: nothing from buildsys? In-Reply-To: <43E33244.7080605@mharris.ca> References: <43E1E0BE.2080908@adslpipe.co.uk> <5256d0b0602020239s3aa68266p37346bfc4d493c12@mail.gmail.com> <43E32AAE.2030703@mharris.ca> <5256d0b0602030211k2631d39cgbbc767d5fb29fbcd@mail.gmail.com> <43E33244.7080605@mharris.ca> Message-ID: <20060207191930.GB5319@ti64.telemetry-investments.com> On Fri, Feb 03, 2006 at 05:36:52AM -0500, Mike A. Harris wrote: > As a total side-question though, just for personal curiousity... > > 1) How many people actually download the SRPMS disk images? I routinely download the SRPMS, though I grab them from the SRPMS/ directories on the servers. Not much interest in the disk images, since after a few weeks there are dozens if not hundreds of updates. > 2) How many people actually really use them for anything? I keep SRPMS for several reasons: o Local modifications I routinely patch: kernel grub SysVinit initscripts util-linux openssh iptables iproute ulogd nfs-utils patch xterm vnc quagga xpdf mdadm postgresql pgadmin3 valgrind gnumeric gaim ... o Creating compat-* packages. I've been saving the various Red Hat compat-*.src.rpm for many years, and when necessary, rolling my own. When we roll forward to a new distribution, we (re-)build compat-* versions of various tools and libraries. I've got vendor object-code interface libraries from RH6.2 and RH7.3. :-( SO, e.g., I coaxed compat-gcc-7.3-2.96.126.src.rpm into building on FC4/FC5t2. o Locally-maintained packages. As some packages have been removed from RH/FC, we have had to maintain them locally. I recently convinced the RHAS 2.1 metamail to build on FC4/FC5t2 x86_64, using patches taken from the original RH package, SuSE, PLD, and local modifications. Also, it's not always the case that newer is better ... Regards, Bill Rugolsky From jkeating at redhat.com Tue Feb 7 19:24:31 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 07 Feb 2006 11:24:31 -0800 Subject: Massive rebuild in progress Message-ID: <1139340272.3579.23.camel@ender> After a late night of staging, I have 900~ packages queued up to rebuild for the gcc4.1 snapshot and glibc changes. These will be submitted to our build system throughout the day as low priority jobs. Some will be finished for tonight's rawhide push, but not all of them. There are still some packages that should be rebuilt that are not in my list, but those package maintainer's have expressed desire to bump their packages themselves. Over the next couple days I'll be checking package timestamps and keeping an eye on what else needs to build. Please bear with the churn and the very lengthy rawhide reports. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jreiser at BitWagon.com Tue Feb 7 19:45:09 2006 From: jreiser at BitWagon.com (John Reiser) Date: Tue, 07 Feb 2006 11:45:09 -0800 Subject: use of downloaded SRPMS Message-ID: <43E8F8C5.60900@BitWagon.com> On Fri, 03 Feb 2006 05:36:52 -0500 Mike A. Harris asked: > 1) How many people actually download the SRPMS disk images? > > 2) How many people actually really use them for anything? I download the SRPMS for RHEL, and for non-test releases of Fedora Core. I frequently modify and rebuild (on both x86 and x86_64): kernel (perfctr extension) glibc (find and fix the bugs) and sometimes gcc (dwarf2 unwind) wvdial,minicom,etc. (dialup seems to be a forgotten stepchild, but it's still required) I also burn a DVD of the SRPMS, and keep it as a defense against possible future license changes which might restrict my activities with respect to then-readily-available sources. -- From roland at redhat.com Tue Feb 7 19:55:47 2006 From: roland at redhat.com (Roland McGrath) Date: Tue, 7 Feb 2006 11:55:47 -0800 (PST) Subject: signal handling: kernel-to-user info leak In-Reply-To: John Reiser's message of Tuesday, 7 February 2006 08:51:03 -0800 <43E8CFF7.50704@BitWagon.com> Message-ID: <20060207195547.469A8180C28@magilla.sf.frob.com> These issues are separate, and I'd prefer to keep separate issues in separate threads. > Somewhat related, the kernel leaks ["garbage"] data from the > kernel stack when placing the struct siginfo onto the user stack. > In arch/i386/kernel/signal.c, subroutine do_signal() declares > an on-stack automatic local > siginfo_t info; > The routine fills in portions without clearing the whole struct, > then copies the entire struct onto the user stack. That's inaccurate. It uses copy_siginfo_to_user (in setup_rt_frame), which copies only the initialized fields. Thanks, Roland From sdl.web at gmail.com Tue Feb 7 19:58:27 2006 From: sdl.web at gmail.com (leon) Date: Tue, 07 Feb 2006 19:58:27 +0000 Subject: Massive rebuild in progress References: <1139340272.3579.23.camel@ender> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating writes: | After a late night of staging, I have 900~ packages queued up to rebuild | for the gcc4.1 snapshot and glibc changes. These will be submitted to | our build system throughout the day as low priority jobs. Some will be | finished for tonight's rawhide push, but not all of them. There are | still some packages that should be rebuilt that are not in my list, but | those package maintainer's have expressed desire to bump their packages | themselves. Over the next couple days I'll be checking package | timestamps and keeping an eye on what else needs to build. Please bear | with the churn and the very lengthy rawhide reports. | | -- | Jesse Keating | Release Engineer: Fedora I'll be waiting until test3 is out. Thanks. - -- .--~~,__ :-....,-------`~~'._.' Dog's year! `-,,, ,_ ;'~U' _,-' ,'`-__; '--. (_/'~~ ''''(; -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFD6PvmkaVrPa103cYRAlRlAJ43Gi/8VJRanYQcshLNHPWGnQ42VQCeM6H+ ISBPAp+pST4MeTUfZMGMgzY= =eRhW -----END PGP SIGNATURE----- From roland at redhat.com Tue Feb 7 20:02:05 2006 From: roland at redhat.com (Roland McGrath) Date: Tue, 7 Feb 2006 12:02:05 -0800 (PST) Subject: signal handling: virtualization In-Reply-To: John Reiser's message of Tuesday, 7 February 2006 08:51:03 -0800 <43E8CFF7.50704@BitWagon.com> Message-ID: <20060207200205.256AD180C28@magilla.sf.frob.com> These issues are separate, and I'd prefer to keep separate issues in separate threads. > My user-mode virtualization of signal handling stopped working in FC5. > I figured out why; the details, and a kernel patch, are in: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180351 > > The dwarf2 unwind info in the vDSO for rt_sigframe, as well as > the kernel rt_sigreturn() itself, takes a shortcut by referencing the > struct ucontext directly, instead of via the puc pointer. This > means that a thread kill to cancel a pthread_cond_wait causes a > SIGSEGV when unwinding through the virtualized rt_sigframe. > (The virtualized frame copies the four scalars {pretcode, sig, > pinfo, puc} while leaving the full structs behind.) > Returning from virtualized signal handler also gets a SIGSEGV > because the kernel uses the ucontext that it "knows" is there, > instead of accessing it indirectly through the pointer puc. You need to take this upstream. Fedora is not going to diverge from the upstream kernel on an issue like this. You are proposing a change to the user ABI for signal handlers. There is no particular indication that the use you're making was ever intended to be supported; perhaps you really just ought to be modifying the context on the stack where the kernel put it. Perhaps people will agree that you change is desireable, and perhaps not. At any rate, this is not the place to carry on the discussion of the details. Thanks, Roland From david at fubar.dk Tue Feb 7 20:07:02 2006 From: david at fubar.dk (David Zeuthen) Date: Tue, 07 Feb 2006 15:07:02 -0500 Subject: OLPC + Fedora = ? In-Reply-To: <43E87240.9010204@warmcat.com> References: <43E87240.9010204@warmcat.com> Message-ID: <1139342822.2952.2.camel@daxter.boston.redhat.com> On Tue, 2006-02-07 at 10:11 +0000, Andy Green wrote: > Hi folks - > > There doesn't seem to be a place to talk about the RH OLPC project yet. Hi, thanks for your email. We (Red Hat) are in the process of setting up mailing lists, documentation, web-sites and code repositories for the OLPC project. It will be ready in a few weeks! Stay tuned! David From jreiser at BitWagon.com Tue Feb 7 20:40:22 2006 From: jreiser at BitWagon.com (John Reiser) Date: Tue, 07 Feb 2006 12:40:22 -0800 Subject: signal handling: virtualization In-Reply-To: <20060207200205.256AD180C28@magilla.sf.frob.com> References: <20060207200205.256AD180C28@magilla.sf.frob.com> Message-ID: <43E905B6.3040505@BitWagon.com> >>My user-mode virtualization of signal handling stopped working in FC5. > You need to take this upstream. ... > At any rate, this is not the place to carry on the discussion of the details. Thank you for the prompt decision. -- From katzj at redhat.com Tue Feb 7 20:46:08 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 07 Feb 2006 15:46:08 -0500 Subject: Updated Xen install instructions Message-ID: <1139345169.2907.18.camel@bree.local.net> I sent mail about this to the Fedora Xen list[1] a little while ago, but there are updated instructions on how to take advantage of Xen in FC5 test2 and later available on the wiki at http://fedoraproject.org/wiki/FedoraXenQuickstartFC5. This will walk you through getting the right packages installed for your host as well as using the nice things now available for doing guest installs via anaconda. Coming soon to that location is some instructions on using the support in Xen for fully virtualized guests given appropriate hardware support. The xenguest-install script in the package I'm building right now (and will be available in rawhide tomorrow) will have this support, I just need to have a little bit of time to write up how to use it. :) Jeremy [1] https://www.redhat.com/mailman/listinfo/fedora-xen -- if you're interested in Xen on Fedora, I highly recommend subscribing. From andy at warmcat.com Tue Feb 7 21:17:24 2006 From: andy at warmcat.com (Andy Green) Date: Tue, 07 Feb 2006 21:17:24 +0000 Subject: OLPC + Fedora = ? In-Reply-To: <1139342822.2952.2.camel@daxter.boston.redhat.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> Message-ID: <43E90E64.20407@warmcat.com> David Zeuthen wrote: > Hi, thanks for your email. We (Red Hat) are in the process of setting up > mailing lists, documentation, web-sites and code repositories for the > OLPC project. It will be ready in a few weeks! Stay tuned! Hi David - Well glad to hear it, I hope these rather fundamental questions will still be in scope by then. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From pjones at redhat.com Tue Feb 7 22:34:00 2006 From: pjones at redhat.com (Peter Jones) Date: Tue, 07 Feb 2006 17:34:00 -0500 Subject: dmraid comments and a warning In-Reply-To: <1139296637.3599.24.camel@mentorng.gurulabs.com> References: <1139256516.4440.66.camel@mentorng.gurulabs.com> <1139277727.1654.28.camel@localhost.localdomain> <1139296637.3599.24.camel@mentorng.gurulabs.com> Message-ID: <1139351640.15968.68.camel@localhost.localdomain> On Tue, 2006-02-07 at 00:17 -0700, Dax Kelson wrote: > On Mon, 2006-02-06 at 21:02 -0500, Peter Jones wrote: > > On Mon, 2006-02-06 at 13:08 -0700, Dax Kelson wrote: > > > The standard root=LABEL=/ was used on the kernel command line and what > > > happened is that it booted up to one side of the mirror. All the updates > > > and new packages (including a new kernel install which modified the > > > grub.conf) activity just happened on that one side of the mirror. Are you sure about this? Your blkid.tab looks very much like you used the default layout on Jan 13... > > This should be fixed in the current rawhide tree. > > And now it uses root=/dev/mapper/$DEV ? No, it still uses root=LABEL=/ (assuming no lvm), but the label searching mechanism early in the boot process is now the same as that used by mount, umount, swapon, etc., and it currently gives device-mapper devices a higher "priority", which should guarantee that, assuming it's possible to build the raid, all of those tools will use the dm device instead of the normal disks. So your blkid.tab says: > /dev/dm-1 > /dev/dm-5 > /dev/dm-2 > /dev/dm-4 > /dev/sda1 > /dev/sda2 > /dev/sdb1 > /dev/sdb2 > /dev/sdb3 > /dev/dm-3 > /dev/VolGroup00/LogVol01 OK, archeology time. On Jan 13, 2006 at about 8pm GMT you installed with the disk layout something like: /dev/sda /dev/sdb -> dm-1 (which would not have gotten an entry in blkid.tab) /dev/sda1 /dev/sdb1 -> dm-2 ntfs (PRI=40, wheras sda1 and sdb1 have PRI=0) /dev/sda2 + /dev/sdb2 -> VolGroup00 (no device node, thus no entry) VolGroup00 -> dm-3 (LogVol01) -> swap dm-4 (LogVol00) -> / (dm-3 vs dm-4 reflects the order they were activated, not necessarily the order on disk) *something happened here, no idea what* Sometime around Feb 4, 2006, at 4pm GMT you rebooted, and the raid didn't get started. This looks like one of your disks wasn't connected at all, and the other was doing weird things. LVM brought up LogVol01, but if both disks were there it would have been complaining about inconsistent VG metadata for VolumeGroup00. For whatever reason, LogVol00 _didn't_ come back up. /boot may or may not have been mounted, we can't say. 25 hours later you walked back into the room and power cycled the box. Then about 26 hours later you rebooted again. This time for some reason the /boot record on /dev/sda2 was modified. This may indicate that sda2 was missing the previous time we booted far enough to get / mounted rw. Once again VolGroup00/LogVol01 was activated correctly, but / was not. The last 2 lines have no PRI= section, that's weird, and might mean my leaf-node test in libblkid is broken. That shouldn't cause the other failures we've seen, though. >From what you say below I'm assuming something went wrong making your initrd on the 4th. > GRUB always sees the "activated" RAID because of the BIOS RAID driver. > When it reads the "grub.conf" it is interleaving pieces of the two (now > different) grub.conf files and the result most likely has bogus syntax > and content. Well, yes and no. It sees a disk as 0x80, and when it does int 13h, the bios decides which disk it's going to send that to. How it decides is anybody's guess; I'm sure it varies wildly between bioses. > Jan 14th 2006 rawhide for event one, and jan 14th 2006 initial install > with yum updates every couple days for event two. Looks like the 13th, but either should be sufficient. > > > On bootup I noticed an error flash by something to the effect of "LVM > > > ignoring duplicate PV". This is the inconsistent metadata error I mentioned above, FWIW. > I booted to the rescue environment with a Jan 14th boot.iso and NFS > tree. The rescue environment properly activated the dmraid and > "pvdisplay" showed "/dev/mapper/nvidia-foo" > > I looked inside the two initrd files I had: > > 2.6.15-1.1884 = dm commands inside "init" OK, so that should work assuming you didn't move the disks around, etc. (I'm working on making moving the disks around ok, but it's a bit complicated so it might take a while) > 2.6.15-1.1889 - no dm commands inside "init" -- dated Feb 4th on my box OK, so if you boot this you're going to get /dev/sda* accessed. Any idea what versions of e2fsprogs, lvm2, util-linux, device-mapper, and mkinitrd were installed? (I'll understand if you don't...) So that means when you installed that, you were either already booted without using raid, or mkinitrd (or one of the many tools it uses) was broken. > > One interesting note is that given any of these you should be getting > > the same disk mounted each time. Which means there's a good chance that > > sda and sdb are both fine, one of them just happens to represent your > > machine 3 weeks ago. > > It installed OK on Jan 14th, and has been successfully booting and using > the dmraid until (I think) Feb 4th. Looks like there was at least one problem before that, or mkinitrd couldn't find the raid devices when you updated that day. > > Do you still have this disk set, or have you wiped it and reinstalled > > already? If you've got it, I'd like to see /etc/blkid.tab from either > > disk (both if possible). > > Since the / filesystem is in a LVM LV sitting ontop of a dmraid > partition PV, it seems non-trivial to force the PV for the LV to change > back and both to access the separate files. If you know a way, let me > know. export the metadata, use vim to rename the volume group, reimport the metadata. I can't recall the commands off the top of my head right now... alternately you can add this to the "device" subsection of /etc/lvm/lvm.conf : filter = [r|sda|] and it'll no longer look at anything with "sda" in the name. > > > There needs to be more checks in place to prevent booting off of one > > > half of the mirror, or at a minimum only allowing a read-only boot on > > > one side of the mirror. Dead systems are no fun. Loosing your personal > > > data is hell. > > > > Well, we should have the appropriate checks there at this point -- so > > I'd be curious to find out exactly which versions you installed with. > > It could be that one of the checks was introduced after you installed, > > and the "yum update" process caused it to believe it was *not* a raid > > system. > > As I noted above I discovered the initramfs for 1884 was OK and had dm > activation commands but the 1889 initramfs did not. Why the change? I > don't know. I've only run yum on the box and haven't touched the LVM or > device mapper config myself. Yeah, that appears to be the 64 kilobuck question. > > (I haven't been extensively checking to make sure every daily rawhide > > would work perfectly as an update from the previous one, just that > > they'd install if possible...) > > > > > This isn't purely a Linux problem. Any operating system using fake RAID1 > > > needs to be robust in this regard. I saw a Windows box using 'fake' > > > motherboard RAID and the motherboard BIOS got flashed which reset the > > > "Use RAID" setting to 'off'. Then Windows booted off of half the RAID. > > > > That's interesting. It means there's some way to query the BIOS to tell > > if it's installed the int13 "raid" hook or not. I wish I knew what that > > magic is. > > Are you sure that's what it means? The motherboard BIOS upgrade turned > off RAID and Windows still booted. That wasn't surprising. The writes to > one side of the mirror and the subsequent re-activation of the mirror > without a proper re-sync in the RAID bios utility caused total foobage. The surprising part is that windows didn't come up exactly as it would with the bios functionality turned on -- RAID included. *nothing* on the disk changes when you switch from "RAID on" to "RAID off" -- only if you edit the volumes. RAID on vs off is a question of if they're hooking into int 13h so the bootloader's disk accesses will go through the BIOS's raid code. > > > The rules are: > > > > > 1. Don't boot off half of the RAID1 in read-write mode > > > > Yeah, we definitely still need some fallback stuff here. > > Excellent. We don't want users complaining that FC5 ate their data. Indeed. Hopefully I can even finish it by then ;) In theory we should (eventually) also be able to read the sync state from several vendors metadata, and do live syncing + metadata update. That's still a ways down the road, though. > > > 3. There is no way to recover from a violated rule 1 without > > > reinstalling. > > > > That's not the case -- you can go into the bios and sync from the > > "newer" disk to the older one. Or if your bios is total junk, you can > > boot some other media and (carefully) re-sync each partition with "dd". > > This should have occurred to me. Since my RAID bios utility is rather > limiting (junk as you say) I overlooked this good suggestion (also noted > by Reuben Farrelly) Note however that it is important to sync the _partitions_. If you do "dd if=/dev/sda of=/dev/sdb", you'll copy the RAID metadata, which isn't necessarily the same on each disk. Also note that this method won't work for RAID0 (obviously ;), nor for RAID5, which we don't support that with dmraid at this time anyway. -- Peter From dax at gurulabs.com Tue Feb 7 23:13:15 2006 From: dax at gurulabs.com (Dax Kelson) Date: Tue, 07 Feb 2006 16:13:15 -0700 Subject: dmraid comments and a warning In-Reply-To: <1139351640.15968.68.camel@localhost.localdomain> References: <1139256516.4440.66.camel@mentorng.gurulabs.com> <1139277727.1654.28.camel@localhost.localdomain> <1139296637.3599.24.camel@mentorng.gurulabs.com> <1139351640.15968.68.camel@localhost.localdomain> Message-ID: <1139353995.3321.24.camel@mentorng.gurulabs.com> On Tue, 2006-02-07 at 17:34 -0500, Peter Jones wrote: > On Tue, 2006-02-07 at 00:17 -0700, Dax Kelson wrote: > > On Mon, 2006-02-06 at 21:02 -0500, Peter Jones wrote: > > > On Mon, 2006-02-06 at 13:08 -0700, Dax Kelson wrote: > > > > The standard root=LABEL=/ was used on the kernel command line and what > > > > happened is that it booted up to one side of the mirror. All the updates > > > > and new packages (including a new kernel install which modified the > > > > grub.conf) activity just happened on that one side of the mirror. > > Are you sure about this? Your blkid.tab looks very much like you used > the default layout on Jan 13... My para was regarding "event one" which got blown away and reinstalled over. The blkid.tab I posted was from the next install I did which used the auto-layout feature of disk druid. > > > This should be fixed in the current rawhide tree. > > > > And now it uses root=/dev/mapper/$DEV ? > > No, it still uses root=LABEL=/ (assuming no lvm), but the label > searching mechanism early in the boot process is now the same as that > used by mount, umount, swapon, etc., and it currently gives > device-mapper devices a higher "priority", which should guarantee that, > assuming it's possible to build the raid, all of those tools will use > the dm device instead of the normal disks. Good to know. > So your blkid.tab says: > > > TYPE="swap">/dev/dm-1 > > /dev/dm-5 > > /dev/dm-2 > > /dev/dm-4 > > /dev/sda1 > > /dev/sda2 > > /dev/sdb1 > > /dev/sdb2 > > /dev/sdb3 > > /dev/dm-3 > > /dev/VolGroup00/LogVol01 > > OK, archeology time. On Jan 13, 2006 at about 8pm GMT you installed > with the disk layout something like: > > /dev/sda /dev/sdb -> dm-1 (which would not have gotten an entry > in blkid.tab) > /dev/sda1 /dev/sdb1 -> dm-2 ntfs (PRI=40, wheras sda1 and sdb1 have > PRI=0) > /dev/sda2 + /dev/sdb2 -> VolGroup00 (no device node, thus no entry) > VolGroup00 -> > dm-3 (LogVol01) -> swap > dm-4 (LogVol00) -> / > > (dm-3 vs dm-4 reflects the order they were activated, not necessarily > the order on disk) > > *something happened here, no idea what* > > Sometime around Feb 4, 2006, at 4pm GMT you rebooted, and the raid > didn't get started. This looks like one of your disks wasn't connected > at all, and the other was doing weird things. LVM brought up LogVol01, > but if both disks were there it would have been complaining about > inconsistent VG metadata for VolumeGroup00. For whatever reason, > LogVol00 _didn't_ come back up. /boot may or may not have been mounted, > we can't say. Physically the disks and their cables haven't been touched. I remember a big yum update that segfaulted half way through. Maybe related? > 25 hours later you walked back into the room and power cycled the box. > Then about 26 hours later you rebooted again. This time for some reason > the /boot record on /dev/sda2 was modified. This may indicate that sda2 > was missing the previous time we booted far enough to get / mounted rw. > Once again VolGroup00/LogVol01 was activated correctly, but / was not. > > The last 2 lines have no PRI= section, that's weird, and might mean my > leaf-node test in libblkid is broken. That shouldn't cause the other > failures we've seen, though. > > >From what you say below I'm assuming something went wrong making your > initrd on the 4th. > > > GRUB always sees the "activated" RAID because of the BIOS RAID driver. > > When it reads the "grub.conf" it is interleaving pieces of the two (now > > different) grub.conf files and the result most likely has bogus syntax > > and content. > > Well, yes and no. It sees a disk as 0x80, and when it does int 13h, the > bios decides which disk it's going to send that to. How it decides is > anybody's guess; I'm sure it varies wildly between bioses. > > > Jan 14th 2006 rawhide for event one, and jan 14th 2006 initial install > > with yum updates every couple days for event two. > > Looks like the 13th, but either should be sufficient. > > > > > On bootup I noticed an error flash by something to the effect of "LVM > > > > ignoring duplicate PV". > > This is the inconsistent metadata error I mentioned above, FWIW. > > > I booted to the rescue environment with a Jan 14th boot.iso and NFS > > tree. The rescue environment properly activated the dmraid and > > "pvdisplay" showed "/dev/mapper/nvidia-foo" > > > > I looked inside the two initrd files I had: > > > > 2.6.15-1.1884 = dm commands inside "init" > > OK, so that should work assuming you didn't move the disks around, etc. > (I'm working on making moving the disks around ok, but it's a bit > complicated so it might take a while) > > > 2.6.15-1.1889 - no dm commands inside "init" -- dated Feb 4th on my box > > OK, so if you boot this you're going to get /dev/sda* accessed. Any > idea what versions of e2fsprogs, lvm2, util-linux, device-mapper, and > mkinitrd were installed? (I'll understand if you don't...) I can look and see tonight when I get home. My guess right now is whatever was in rawhide at that time. > So that means when you installed that, you were either already booted > without using raid, or mkinitrd (or one of the many tools it uses) was > broken. Yes. I'm sure I didn't closely observe every bootup sequence or was even in the room while the boot occurred so it would be easy for me to have missed something. > > > One interesting note is that given any of these you should be getting > > > the same disk mounted each time. Which means there's a good chance that > > > sda and sdb are both fine, one of them just happens to represent your > > > machine 3 weeks ago. > > > > It installed OK on Jan 14th, and has been successfully booting and using > > the dmraid until (I think) Feb 4th. > > Looks like there was at least one problem before that, or mkinitrd > couldn't find the raid devices when you updated that day. > > > > Do you still have this disk set, or have you wiped it and reinstalled > > > already? If you've got it, I'd like to see /etc/blkid.tab from either > > > disk (both if possible). > > > > Since the / filesystem is in a LVM LV sitting ontop of a dmraid > > partition PV, it seems non-trivial to force the PV for the LV to change > > back and both to access the separate files. If you know a way, let me > > know. > > export the metadata, use vim to rename the volume group, reimport the > metadata. I can't recall the commands off the top of my head right > now... > > alternately you can add this to the "device" subsection > of /etc/lvm/lvm.conf : > > filter = [r|sda|] > > and it'll no longer look at anything with "sda" in the name. I can attempt this if you still want. Dax Kelson Guru Labs From lamont at gurulabs.com Tue Feb 7 23:22:38 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Tue, 7 Feb 2006 16:22:38 -0700 Subject: dmraid comments and a warning In-Reply-To: <1139351640.15968.68.camel@localhost.localdomain> References: <1139256516.4440.66.camel@mentorng.gurulabs.com> <1139296637.3599.24.camel@mentorng.gurulabs.com> <1139351640.15968.68.camel@localhost.localdomain> Message-ID: <200602071622.42894.lamont@gurulabs.com> On Tuesday 07 February 2006 03:34pm, Peter Jones wrote: > On Tue, 2006-02-07 at 00:17 -0700, Dax Kelson wrote: [snip] > > And now it uses root=/dev/mapper/$DEV ? > > No, it still uses root=LABEL=/ (assuming no lvm), but the label > searching mechanism early in the boot process is now the same as that > used by mount, umount, swapon, etc., and it currently gives > device-mapper devices a higher "priority", which should guarantee that, > assuming it's possible to build the raid, all of those tools will use > the dm device instead of the normal disks. Perhaps it would be better to have this defaulted on install to *not* use LABEL= mounting syntax. In that case, the broken device would have prevented mounting and, therefore, booting and the problem of dropping half the mirror leading to this corruption would not happen without FRAID users knowing about it. Yet another case where mounting using LABEL= syntax causes more problems than it solves. [snip] -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lamont at gurulabs.com Tue Feb 7 23:26:28 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Tue, 7 Feb 2006 16:26:28 -0700 Subject: dmraid comments and a warning In-Reply-To: <1139296637.3599.24.camel@mentorng.gurulabs.com> References: <1139256516.4440.66.camel@mentorng.gurulabs.com> <1139277727.1654.28.camel@localhost.localdomain> <1139296637.3599.24.camel@mentorng.gurulabs.com> Message-ID: <200602071626.33773.lamont@gurulabs.com> On Tuesday 07 February 2006 12:17am, Dax Kelson wrote: [snip] > I booted to the rescue environment with a Jan 14th boot.iso and NFS > tree. The rescue environment properly activated the dmraid and > "pvdisplay" showed "/dev/mapper/nvidia-foo" > > I looked inside the two initrd files I had: > > 2.6.15-1.1884 = dm commands inside "init" > 2.6.15-1.1889 - no dm commands inside "init" -- dated Feb 4th on my box I would think that is the fault of mkinitrd. At any rate, we need to test if mkinitrd will bring the right FRAID driver(s) into initrds that it creates. Perhaps the mirror broke the first time you booted with the new kernel. [snip] -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gazzerh at gmail.com Wed Feb 8 00:44:13 2006 From: gazzerh at gmail.com (Garry Harthill) Date: Wed, 8 Feb 2006 00:44:13 +0000 Subject: Sunbird in Rawhide Message-ID: <1fcc9e320602071644o2ad2e039k@mail.gmail.com> Last time this was mensioned was middle of last year and I was wondering if Mozilla Sunbird going to be included in Rawhide in the near future? It looks a very interesting application and would like to see inclusion into Fedora at some point. Evolutions Exchange plug-in is driving me mad. Fedora needs a decent calender app - and soon. Garry From wolverine_ at mac.com Wed Feb 8 01:44:58 2006 From: wolverine_ at mac.com (Adam Huda) Date: Tue, 7 Feb 2006 17:44:58 -0800 Subject: Updated Xen install instructions In-Reply-To: <1139345169.2907.18.camel@bree.local.net> References: <1139345169.2907.18.camel@bree.local.net> Message-ID: <65299158-006A-4641-9409-D4EBC16013C2@mac.com> Jeremy, I've been following http://fedoraproject.org/wiki/ FedoraXenQuickstartFC5. I've booted into the xen hypervisor kernel, but I'm having problems installing a guest os. After http://people.redhat.com/~katzj/xenguest-install.py passes control to Anaconda. Anacoda proceeds to download stage2 and when the download completes, I see this error: from booty import * File "/usr/lib/booty/booty.py", line 28, in ? from bootloaderInfo import * File "/usr/lib/booty/bootloaderInfo.py", line 713 if grubTarget[-2] == 'p' or ^ SyntaxError: invalid syntax install exited abnormally sending termination signals...done sending kill signals...done disabling swap... unmounting filesystems... /mnt/runtime done disabling /dev/loop0 /proc done /dev/pts done /sys done /tmp/ramfs done /selinux done you may safely reboot your system Unfortunately, I can't scroll up to see the start of the output. Any ideas how to work around this? Thanks Adam On Feb 7, 2006, at 12:46 PM, Jeremy Katz wrote: > I sent mail about this to the Fedora Xen list[1] a little while > ago, but > there are updated instructions on how to take advantage of Xen in FC5 > test2 and later available on the wiki at > http://fedoraproject.org/wiki/FedoraXenQuickstartFC5. This will walk > you through getting the right packages installed for your host as well > as using the nice things now available for doing guest installs via > anaconda. > > Coming soon to that location is some instructions on using the support > in Xen for fully virtualized guests given appropriate hardware > support. > The xenguest-install script in the package I'm building right now (and > will be available in rawhide tomorrow) will have this support, I just > need to have a little bit of time to write up how to use it. :) > > Jeremy > > [1] https://www.redhat.com/mailman/listinfo/fedora-xen -- if you're > interested in Xen on Fedora, I highly recommend subscribing. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From jwboyer at jdub.homelinux.org Wed Feb 8 00:50:50 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 07 Feb 2006 19:50:50 -0500 Subject: Updated Xen install instructions In-Reply-To: <65299158-006A-4641-9409-D4EBC16013C2@mac.com> References: <1139345169.2907.18.camel@bree.local.net> <65299158-006A-4641-9409-D4EBC16013C2@mac.com> Message-ID: <1139359850.32218.9.camel@yoda.jdub.homelinux.org> On Tue, 2006-02-07 at 17:44 -0800, Adam Huda wrote: > Jeremy, > > I've been following http://fedoraproject.org/wiki/ > FedoraXenQuickstartFC5. I've booted into the xen hypervisor kernel, > but I'm having problems installing a guest os. > > After http://people.redhat.com/~katzj/xenguest-install.py passes > control to Anaconda. Anacoda proceeds to download stage2 and when the > download completes, I see this error: > > from booty import * > File "/usr/lib/booty/booty.py", line 28, in ? > from bootloaderInfo import * > File "/usr/lib/booty/bootloaderInfo.py", line 713 > if grubTarget[-2] == 'p' or > ^ > SyntaxError: invalid syntax > install exited abnormally > sending termination signals...done > sending kill signals...done > disabling swap... > unmounting filesystems... > /mnt/runtime done > disabling /dev/loop0 > /proc done > /dev/pts done > /sys done > /tmp/ramfs done > /selinux done > you may safely reboot your system > > Unfortunately, I can't scroll up to see the start of the output. Any > ideas how to work around this? That's actually a syntax error in booty. It has nothing to do with xen itself. I think it will be fixed tomorrow in rawhide. josh From nman64 at n-man.com Wed Feb 8 01:55:50 2006 From: nman64 at n-man.com (Patrick Barnes) Date: Tue, 7 Feb 2006 19:55:50 -0600 Subject: Sunbird in Rawhide In-Reply-To: <1fcc9e320602071644o2ad2e039k@mail.gmail.com> References: <1fcc9e320602071644o2ad2e039k@mail.gmail.com> Message-ID: <200602071955.53424.nman64@n-man.com> On Tuesday 07 February 2006 18:44, Garry Harthill wrote: > Last time this was mensioned was middle of last year and I was > wondering if Mozilla Sunbird going to be included in Rawhide in the > near future? It looks a very interesting application and would like to > see inclusion into Fedora at some point. > > Evolutions Exchange plug-in is driving me mad. Fedora needs a decent > calender app - and soon. > > Garry It *shouldn't* be. * It is still in the early stages of development. * Initially, it would belong in Extras, not Core. There are a number of other calendaring applications available in Fedora Core and Extras already. I personally use KDE and the KOrganizer application (from the kdepim package). It has all of the features of Sunbird, plus several more, and it has fewer bugs. If you really want to see Sunbird become available, you're welcome to try packaging it and submitting it to Extras, but with the early stage it is currently in, and with its slow development so far, it will likely otherwise be a long time before you'll see it in Fedora. Note that the current CVS version does /not/ build correctly on Fedora Core. http://fedoraproject.org/wiki/Extras Note also that the current preferred direction of Mozilla is using the Lightning extension to Thunderbird, rather than the standalone Sunbird application. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ -- Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From naoki at valuecommerce.com Wed Feb 8 03:15:48 2006 From: naoki at valuecommerce.com (Naoki) Date: Wed, 08 Feb 2006 12:15:48 +0900 Subject: Testing Xen. Some quick questions. Message-ID: <1139368548.2603.35.camel@dragon.sys.intra> http://fedoraproject.org/wiki/FedoraXenQuickstart & http://fedoraproject.org/wiki/FedoraXenQuickstartFC5 I'm just running through these instructions as a reference for my Xen3 tests on rawhide and all is going pretty well. I have a test domain (but can't alter the number of VCPUs for some reason but that's another story) and I'm wondering. Rather than the pretty ugly system of either : Make an image file. Mount. yum --installroot=blah groupinstall x y z Configure. Or the much better system of /usr/sbin/xenguest-install.py, Is there a simple way to fake a netboot so I can use my existing kickstart scripts and build OS instances the same way I would with normal physical hardware? It would be nice to have my hypervisor instance running dhcp + apache and do localhost kickstart network installs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at fubar.dk Wed Feb 8 03:32:53 2006 From: david at fubar.dk (David Zeuthen) Date: Tue, 07 Feb 2006 22:32:53 -0500 Subject: OLPC + Fedora = ? In-Reply-To: <43E90E64.20407@warmcat.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> Message-ID: <1139369574.3279.34.camel@daxter.boston.redhat.com> On Tue, 2006-02-07 at 21:17 +0000, Andy Green wrote: > David Zeuthen wrote: > > > Hi, thanks for your email. We (Red Hat) are in the process of setting up > > mailing lists, documentation, web-sites and code repositories for the > > OLPC project. It will be ready in a few weeks! Stay tuned! > > Hi David - > > Well glad to hear it, I hope these rather fundamental questions will > still be in scope by then. Yes, things are definitely not set in stone yet. To comment on the list in your original mail.. it seems pretty good and thoughtful though it's probably a bit premature to discuss this at such a great detail. Indulge some rambling... Our current thinking (and code) revolves partly around making it easier to build derived lean distributions based on Fedora Core. All this includes fixing a few obvious and not-so-obvious things in Core; it includes lots of thinking about distribution and updates in scenarios that the OLPC project targets (e.g. millions of users, extremely low admin/user ratios, think appliance); it includes thoughts about how lock down and provide a secure OS out of the box; it includes thinking about how to fit this in almost no space with very limited RAM and worse.. no swap; it includes thinking about how to easily enable application developers and other stake holders to participate... and a whole bunch of other stuff too.. It's also useful to keep in mind that the software side of the OLPC project is larger than the bits Red Hat will provide - there's a bunch of smart people thinking about... not so much how we provide the bits in a sane way to users (all the stuff in the paragraph above)... but what bits we should be providing... for example, it's not at all a given to me that we want the target users (they are kids!) to sit down and learn a difficult program like openoffice.org Writer.. (this doesn't mean that I don't like oo.o) Anyway, it's probably not useful to start a huge thread here about these high-level thoughts (read: no need to reply)... First of all we need a dedicated mailing list and other infrastructure since a) this is sort of off-topic for f-d-l; and b) the S/N ratio here is simply too huge to have a constructive discussion. Second, and more important probably, we want to provide some bits you can try out along with some written-down thoughts. We want future contributors have a good starting point so we're all on the same page. And we're there pretty soon. Stay tuned! Thanks, David From canfield at uindy.edu Wed Feb 8 03:42:24 2006 From: canfield at uindy.edu (D Canfield) Date: Tue, 07 Feb 2006 22:42:24 -0500 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <20060206195913.GB30359@redhat.com> References: <1139006387.2652.29.camel@bree.local.net> <1139014200.2863.65.camel@yoda.loki.me> <43E48DDD.4060508@vip.hr> <200602041255.23869.lamont@gurulabs.com> <43E5095E.3060804@mharris.ca> <43E6763A.8050509@uindy.edu> <43E7186E.7050307@redhat.com> <1139243683.3188.14.camel@yoda.loki.me> <20060206195913.GB30359@redhat.com> Message-ID: <43E968A0.7060609@uindy.edu> Dave Jones wrote: > On Mon, Feb 06, 2006 at 08:34:43AM -0800, Jesse Keating wrote: > > On Mon, 2006-02-06 at 04:35 -0500, Christopher Aillon wrote: > > > Suspend should be working for FC5, especially on thinkpads. Works great > > > on my T41 at least. > > > > > > > Suspend on T42 yes. Resume? Kind of. I resume it goes RIGHT back to > > sleep, so I have to fiddle w/ the lid button once to get it to wake back > > up again. > > > > How are you doing the suspend ? Are you writing to /sys/power/sleep yourself, > or using a helper like pm-suspend ? > > pm-suspend should be doing all the necessary hacking around with the button > module itself in latest builds. > > Dave > > Resume now works on my T43 after I comment out the DRI option in xorg.conf. I have an ATI chipset. Only other resume problem is that NetworkManager doesn't know that I have any network interfaces after a resume. I can restart the network (through init.d), but NM still doesn't see any interfaces. DC From katzj at redhat.com Wed Feb 8 04:07:41 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 07 Feb 2006 23:07:41 -0500 Subject: Testing Xen. Some quick questions. In-Reply-To: <1139368548.2603.35.camel@dragon.sys.intra> References: <1139368548.2603.35.camel@dragon.sys.intra> Message-ID: <1139371661.2907.66.camel@bree.local.net> On Wed, 2006-02-08 at 12:15 +0900, Naoki wrote: > I'm just running through these instructions as a reference for my Xen3 > tests on rawhide and all is going pretty well. Good to hear > I have a test domain (but can't alter the number of VCPUs for some > reason but that's another story) and I'm wondering. Rather than the > pretty ugly system of either : Yeah, vcpu hotplug seems to be a little busted right now. Haven't really dug to figure out why yet. > Or the much better system of /usr/sbin/xenguest-install.py, > > Is there a simple way to fake a netboot so I can use my existing > kickstart scripts and build OS instances the same way I would with > normal physical hardware? Realistically, the xenguest-install stuff is pretty much faking netboot. Run it with --help to see the way to pass the various things to it as command line arguments and you can use -x for passing things like ks= Jeremy From rc040203 at freenet.de Wed Feb 8 04:27:39 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 08 Feb 2006 05:27:39 +0100 Subject: rawhide report: 20060207 changes In-Reply-To: <1139334073.4897.16.camel@localhost> References: <200602070834.k178YGVA017981@porkchop.devel.redhat.com> <1139309034.1084.53.camel@mccallum.corsepiu.local> <43E890F1.9060903@mharris.ca> <1139334073.4897.16.camel@localhost> Message-ID: <1139372859.1084.112.camel@mccallum.corsepiu.local> On Tue, 2006-02-07 at 09:41 -0800, Toshio Kuratomi wrote: > On Tue, 2006-02-07 at 07:22 -0500, Mike A. Harris wrote: > > If a package wishes to retain build time compatibility with > > X11R6 et al. it could use fallbacks if the pkg-config files > > aren't present, however from here on out, using pkgconfig > > is the very highly recommended way to detect the X libraries > > and other bits and pieces. > > > Where should this be implemented? Inside of a package's configure script. What Mike says, basically boils down to treat "X libs" as you would handle other libraries. The most simple but also most flexible approach would be to use AC_CHECK_HEADERS/AC_CHECK_LIBS on each of the files being used by a package. This essentially means shifting selection of directories/paths to the user (configure CPPFLAGS=-I/usr/X11R6/include LDFLAGS=-L/usr/X11R6/lib) However, in practice, this is hardly applicable on X11 packages (It is the reason why AC_PATH_X* exist) :( > Should AC_PATH_X/XTRA be changed to > attempt to use pkgconfig as a first choice and then use AC_PATH_X if it > isn't found? (I don't know how autoconf deals with dependencies on > optional m4 macros but for now I'm supposing this is possible) Providing aclocal macros/wrappers around pkg-config is task of the package providing the *.pc-file, i.e. each of those X11-libraries would have to provide them (c.f. how gtk/gnome handles this). > Or does every package using AC_PATH_X need to create the logic for using > pkg-config with optional fallbacks to X11R6 behavior and then try to > push those changes upstream (using autoconf/autoconf-patches until the > changes are accepted and released.) It depends. As I see it, you have 4 choices: 1. Use the old fsf-autoconf behavior: I.e. use AC_PATH_X* with the check for Xt, and presume all X11 files to be installed to the same directories. Rpm-wise, you'd have to "BR: libXt-devel" in all such packages, and the behavior should be the same as it has been so far. This would be the "short term and least invasive" approach. 2. Treat X11 libs as normal libs, and check for each file required manually. Due to the number of libs being involved into X11 this is very tedious and hardly possible. However, as long as all X11 libs are installed to the same directories, the "sloppy method" of checking for a subset of libs/headers and presuming other libs/headers to be pulled in implicitly, often is sufficient. 3. Rely on the X11R7-packages providing appropriate *.pc files, and abandon X11R6. Then using PKG_CHECK_MODULES(...) in configure scripts should be sufficient. This is the most simple approach, but means breaking backward compatibility. 4. Pragmatically combine 1-3. I'd expect combining 3 + 1 is what would be the "common approach". Ralf From fcd-cornette at insight.rr.com Wed Feb 8 04:56:16 2006 From: fcd-cornette at insight.rr.com (Jim Cornette) Date: Tue, 07 Feb 2006 23:56:16 -0500 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <1139243683.3188.14.camel@yoda.loki.me> References: <1139006387.2652.29.camel@bree.local.net> <1139014200.2863.65.camel@yoda.loki.me> <43E48DDD.4060508@vip.hr> <200602041255.23869.lamont@gurulabs.com> <43E5095E.3060804@mharris.ca> <43E6763A.8050509@uindy.edu> <43E7186E.7050307@redhat.com> <1139243683.3188.14.camel@yoda.loki.me> Message-ID: <43E979F0.6000407@insight.rr.com> Jesse Keating wrote: > On Mon, 2006-02-06 at 04:35 -0500, Christopher Aillon wrote: >> Suspend should be working for FC5, especially on thinkpads. Works great >> on my T41 at least. >> > > Suspend on T42 yes. Resume? Kind of. I resume it goes RIGHT back to > sleep, so I have to fiddle w/ the lid button once to get it to wake back > up again. > > Hibernate? Not so much. Never fully goes into hibernate, just pops > back out. > > Same problem with hibernation for me, It cycles out. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178157 Jim From rtlm10 at gmail.com Wed Feb 8 05:03:58 2006 From: rtlm10 at gmail.com (Russell Harrison) Date: Wed, 8 Feb 2006 00:03:58 -0500 Subject: Sunbird in Rawhide In-Reply-To: <1fcc9e320602071644o2ad2e039k@mail.gmail.com> References: <1fcc9e320602071644o2ad2e039k@mail.gmail.com> Message-ID: <1ed4a0130602072103ma030c5bib9808bbbcb8461a7@mail.gmail.com> On 2/7/06, Garry Harthill wrote: > > Evolutions Exchange plug-in is driving me mad. Fedora needs a decent > calender app - and soon. > Garry, It drives us all mad, but it all we've got that integrates with exchange at all. It should be noted that sunbird is a stand alone application and doesn't integrate with exchange or allow you to sync to a PDA. I'm really rooting for Lightning myself, I'd love to have a crossplatform open source Outlook killer out there. Russell -------------- next part -------------- An HTML attachment was scrubbed... URL: From naoki at valuecommerce.com Wed Feb 8 05:30:13 2006 From: naoki at valuecommerce.com (Naoki) Date: Wed, 08 Feb 2006 14:30:13 +0900 Subject: Testing Xen. Some quick questions. In-Reply-To: <1139371661.2907.66.camel@bree.local.net> References: <1139368548.2603.35.camel@dragon.sys.intra> <1139371661.2907.66.camel@bree.local.net> Message-ID: <1139376613.17114.37.camel@dragon.sys.intra> > > Is there a simple way to fake a netboot so I can use my existing > > kickstart scripts and build OS instances the same way I would with > > normal physical hardware? > > Realistically, the xenguest-install stuff is pretty much faking netboot. > Run it with --help to see the way to pass the various things to it as > command line arguments and you can use -x for passing things like ks= As we say in my country, "Sweet mate!". I've tested with current rawhide and it's looking good except for the stage2 problem which I think has already been covered today. Quick note about -l LOCATION, --location=LOCATION : "http://host:/path" may be confusing because it will not work with the middle ":" unless a port is specified. Perhaps "http://host:port/path" is better? From wolverine_ at mac.com Wed Feb 8 06:15:48 2006 From: wolverine_ at mac.com (Adam Huda) Date: Tue, 7 Feb 2006 22:15:48 -0800 Subject: Testing Xen. Some quick questions. In-Reply-To: <1139376613.17114.37.camel@dragon.sys.intra> References: <1139368548.2603.35.camel@dragon.sys.intra> <1139371661.2907.66.camel@bree.local.net> <1139376613.17114.37.camel@dragon.sys.intra> Message-ID: <04238730-1E23-4018-96E6-C3F31DD0A8D8@mac.com> The error I reported earlier actually occurs after bug 177644. Sorry about that. One suggestion for xenguest-install.py. You might want to set the initial value of ram to 256. It is a little confusing when it prints out "ERROR: Installs currently require 256 megs of RAM." in interactive mode (running without any command line args) before your prompted with "How much RAM should be allocated (in megabytes)? ". On Feb 7, 2006, at 9:30 PM, Naoki wrote: > >>> Is there a simple way to fake a netboot so I can use my existing >>> kickstart scripts and build OS instances the same way I would with >>> normal physical hardware? >> >> Realistically, the xenguest-install stuff is pretty much faking >> netboot. >> Run it with --help to see the way to pass the various things to it as >> command line arguments and you can use -x for passing things like ks= > > As we say in my country, "Sweet mate!". I've tested with current > rawhide and it's looking good except for the stage2 problem which I > think has already been covered today. > > Quick note about -l LOCATION, --location=LOCATION : > > "http://host:/path" may be confusing because it will not work with the > middle ":" unless a port is specified. Perhaps "http://host:port/ > path" > is better? > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From 777tahder at schlaegel.com Wed Feb 8 07:02:17 2006 From: 777tahder at schlaegel.com (Schlaegel) Date: Tue, 7 Feb 2006 23:02:17 -0800 Subject: Xorg 6.9 Update for FC4? In-Reply-To: <4e1f5c1a0602052032n4b97805du97c436a5f6952e66@mail.gmail.com> References: <43E508B9.80702@gmx.net> <25327.194.94.224.254.1139130574.squirrel@arlette.freesurf.fr> <4e1f5c1a0602052032n4b97805du97c436a5f6952e66@mail.gmail.com> Message-ID: <4e1f5c1a0602072302jbb00b01u61ed25c2536ec473@mail.gmail.com> On 2/5/06, Schlaegel <777tahder at schlaegel.com> wrote: > > I tried to install those packages today via yum, but it seems that their > xorg-x11-Xnest and xorg-x11-devel packages need xorg-x11 and xorg-x11-libs > packages with a version at or higher than 6.9.0-1, while the site only > offers 6.9.0. Perhaps the site is in the middle of an update. > > My yum error: > > xorg-x11-6.9-0.FC4.ucr.5. 100% |=========================| 173 > kB 00:24 > > ---> Package xorg-x11.i386 0:6.9-0.FC4.ucr.5 set to be updated > [snip] > > Error: Missing Dependency: xorg-x11 = 6.9.0-1 is needed by package > xorg-x11-Xnest > > Error: Missing Dependency: xorg-x11-libs = 6.9.0-1 is needed by package > xorg-x11-devel > My error! I had a partial install from my failed attempt to use the kit at http://sergiomb.no-ip.org/xorg/. I have now successfully installed a rebuild of those rpms from the src rpm, but haven't had time to see if they work for me. Even so, I would still love a version with the mharris magic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.mailhot at laposte.net Wed Feb 8 07:34:42 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 08 Feb 2006 08:34:42 +0100 Subject: OLPC + Fedora = ? In-Reply-To: <1139369574.3279.34.camel@daxter.boston.redhat.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> Message-ID: <1139384082.15809.2.camel@rousalka.dyndns.org> Le mardi 07 f?vrier 2006 ? 22:32 -0500, David Zeuthen a ?crit : > It's also useful to keep in mind that the software side of the OLPC > project is larger than the bits Red Hat will provide - there's a bunch > of smart people thinking about... not so much how we provide the bits in > a sane way to users (all the stuff in the paragraph above)... but what > bits we should be providing... for example, it's not at all a given to > me that we want the target users (they are kids!) to sit down and learn > a difficult program like openoffice.org Writer.. (this doesn't mean that > I don't like oo.o) So work through Fedora Extras. Please do not segregate OLPC packages where other projects can not benefit. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jkeating at redhat.com Wed Feb 8 07:42:58 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 07 Feb 2006 23:42:58 -0800 Subject: OLPC + Fedora = ? In-Reply-To: <1139384082.15809.2.camel@rousalka.dyndns.org> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> <1139384082.15809.2.camel@rousalka.dyndns.org> Message-ID: <1139384578.3579.39.camel@ender> On Wed, 2006-02-08 at 08:34 +0100, Nicolas Mailhot wrote: > So work through Fedora Extras. Please do not segregate OLPC packages > where other projects can not benefit. Some of the content that goes into OLPC may not be appropriate for Extras. Things are still being worked out, please have patience. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From gazzerh at gmail.com Wed Feb 8 08:36:23 2006 From: gazzerh at gmail.com (Garry Harthill) Date: Wed, 8 Feb 2006 08:36:23 +0000 Subject: Sunbird in Rawhide In-Reply-To: <1ed4a0130602072103ma030c5bib9808bbbcb8461a7@mail.gmail.com> References: <1fcc9e320602071644o2ad2e039k@mail.gmail.com> <1ed4a0130602072103ma030c5bib9808bbbcb8461a7@mail.gmail.com> Message-ID: <1fcc9e320602080036s4c4c90e2s@mail.gmail.com> On 08/02/06, Russell Harrison wrote: > Garry, > > It drives us all mad, but it all we've got that integrates with exchange at > all. It should be noted that sunbird is a stand alone application and > doesn't integrate with exchange or allow you to sync to a PDA. I'm really > rooting for Lightning myself, I'd love to have a crossplatform open source > Outlook killer out there. > > Russell I like the fact the Sunbird can connect to a WebDAV server on Apache and store it's calenders there. This mean people can share calenders and have similar functionality as users of shared calenders on exchange. I have almost given up with a decent exchange connector for any app and this looks like a decent alternative for group ca lander sharing. I would just like to test it. It would be nice to see it in development-extras at some point. Garry From buildsys at redhat.com Wed Feb 8 08:40:41 2006 From: buildsys at redhat.com (Build System) Date: Wed, 8 Feb 2006 03:40:41 -0500 Subject: rawhide report: 20060208 changes Message-ID: <200602080840.k188efVd027329@porkchop.devel.redhat.com> Updated Packages: MAKEDEV-3.21-2 -------------- * Tue Feb 07 2006 Nalin Dahyabhai 3.21-2 - rebuild a2ps-4.13b-48.2.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 4.13b-48.2.2 - rebuilt for new gcc4.1 snapshot and glibc changes acl-2.2.34-1.1 -------------- * Tue Feb 07 2006 Jesse Keating - 2.2.34-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes acpid-1.0.4-1.2 --------------- * Tue Feb 07 2006 Jesse Keating - 1.0.4-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes adjtimex-1.20-1.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 1.20-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes agg-2.3-1.1 ----------- alchemist-1.0.36-1.2 -------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.36-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes alsa-lib-1.0.11-3.rc2.1 ----------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.11-3.rc2.1 - rebuilt for new gcc4.1 snapshot and glibc changes alsa-utils-1.0.11-2.rc2.1 ------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.11-2.rc2.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Wed Jan 25 2006 Martin Stransky 1.0.11-2.rc2 - added volume option to alsaunmute utility (for s-c-s) amanda-2.4.5p1-3.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 2.4.5p1-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes amtu-1.0.4-2.1 -------------- * Tue Feb 07 2006 Jesse Keating - 1.0.4-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes ant-0:1.6.5-1jpp_5fc -------------------- * Tue Feb 07 2006 Jesse Keating - 0:1.6.5-1jpp_5fc - rebuilt for new gcc4.1 snapshot and glibc changes anthy-7100b-2.2 --------------- * Tue Feb 07 2006 Jesse Keating - 7100b-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes apmd-1:3.2.2-3.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 1:3.2.2-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes apr-1.2.2-7.1 ------------- * Tue Feb 07 2006 Jesse Keating - 1.2.2-7.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Wed Jan 04 2006 Joe Orton 1.2.2-7 - fix namespace pollution (r354824, r355464) * Wed Jan 04 2006 Joe Orton 1.2.2-6 - fix build with recent glibc (#176911) apr-util-1.2.2-4.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 1.2.2-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes aqbanking-1.8.1beta-3 --------------------- * Tue Feb 07 2006 Karsten Hopp 1.8.1beta-3 - buildrequire libofx-devel instead of libofx (pulls in libofx) * Tue Feb 07 2006 Jesse Keating - 1.8.1beta-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes arptables_jf-0:0.0.8-6.2 ------------------------ * Tue Feb 07 2006 Jesse Keating - 0:0.0.8-6.2 - rebuilt for new gcc4.1 snapshot and glibc changes aspell-12:0.60.3-3.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 12:0.60.3-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Mon Dec 19 2005 Ivana Varekova 12:0.60.3-3 - fix for gcc 4.1 aspell-af-50:0.50-4.2 --------------------- * Tue Feb 07 2006 Jesse Keating - 50:0.50-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes aspell-bg-50:0.50-11.2 ---------------------- * Tue Feb 07 2006 Jesse Keating - 50:0.50-11.2 - rebuilt for new gcc4.1 snapshot and glibc changes aspell-br-50:0.50-4.2 --------------------- * Tue Feb 07 2006 Jesse Keating - 50:0.50-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes aspell-ca-50:0.50-4.2 --------------------- * Tue Feb 07 2006 Jesse Keating - 50:0.50-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes aspell-cs-50:0.51-3.2 --------------------- * Tue Feb 07 2006 Jesse Keating - 50:0.51-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes aspell-cy-50:0.50-4.2 --------------------- * Tue Feb 07 2006 Jesse Keating - 50:0.50-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes aspell-da-50:0.50-12.2 ---------------------- * Tue Feb 07 2006 Jesse Keating - 50:0.50-12.2 - rebuilt for new gcc4.1 snapshot and glibc changes aspell-de-50:0.50-11.2 ---------------------- * Tue Feb 07 2006 Jesse Keating - 50:0.50-11.2 - rebuilt for new gcc4.1 snapshot and glibc changes aspell-el-50:0.50-4.2 --------------------- * Tue Feb 07 2006 Jesse Keating - 50:0.50-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes aspell-en-50:6.0-1.2 -------------------- * Tue Feb 07 2006 Jesse Keating - 50:6.0-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes aspell-es-50:0.50-13.2 ---------------------- * Tue Feb 07 2006 Jesse Keating - 50:0.50-13.2 - rebuilt for new gcc4.1 snapshot and glibc changes aspell-fo-50:0.51-4.2 --------------------- * Tue Feb 07 2006 Jesse Keating - 50:0.51-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes aspell-fr-50:0.50-9.2 --------------------- * Tue Feb 07 2006 Jesse Keating - 50:0.50-9.2 - rebuilt for new gcc4.1 snapshot and glibc changes aspell-gd-50:0.50-4.2 --------------------- * Tue Feb 07 2006 Jesse Keating - 50:0.50-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes aspell-gl-50:0.50-4.2 --------------------- * Tue Feb 07 2006 Jesse Keating - 50:0.50-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes aspell-id-50:0.50.1-4.2 ----------------------- * Tue Feb 07 2006 Jesse Keating - 50:0.50.1-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes aspell-it-50:0.53-4.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 50:0.53-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Tue Jan 24 2006 Ivana Varekova 50:0.53-4 - fix typo (bug 178755) * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj aspell-nl-50:0.50-8.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 50:0.50-8.1 - rebuilt for new gcc4.1 snapshot and glibc changes aspell-no-50:0.50.1-9.2 ----------------------- * Tue Feb 07 2006 Jesse Keating - 50:0.50.1-9.2 - rebuilt for new gcc4.1 snapshot and glibc changes aspell-pl-50:0.51-5.2 --------------------- * Tue Feb 07 2006 Jesse Keating - 50:0.51-5.2 - rebuilt for new gcc4.1 snapshot and glibc changes aspell-pt-50:0.50-10.2 ---------------------- * Tue Feb 07 2006 Jesse Keating - 50:0.50-10.2 - rebuilt for new gcc4.1 snapshot and glibc changes aspell-ru-50:0.99f7-2.2 ----------------------- * Tue Feb 07 2006 Jesse Keating - 50:0.99f7-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes aspell-sl-50:0.50-1.1 --------------------- aspell-sr-50:0.02-1.1 --------------------- aspell-sv-50:0.51-1.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 50:0.51-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes at-spi-1.7.4-1.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 1.7.4-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes atk-1.11.2-1.1 -------------- * Tue Feb 07 2006 Jesse Keating - 1.11.2-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes audiofile-1:0.2.6-2.2 --------------------- * Tue Feb 07 2006 Jesse Keating - 1:0.2.6-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes audit-1.1.3-1.1 --------------- * Tue Feb 07 2006 Jesse Keating - 1.1.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes authconfig-5.2.0-1.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 5.2.0-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes authd-1.4.3-6.devel.2 --------------------- * Tue Feb 07 2006 Jesse Keating - 1.4.3-6.devel.2 - rebuilt for new gcc4.1 snapshot and glibc changes autofs-1:4.1.4-16.2.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 1:4.1.4-16.2.1 - rebuilt for new gcc4.1 snapshot and glibc changes awesfx-0.5.0d-3.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 0.5.0d-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes bash-3.1-6.1 ------------ * Tue Feb 07 2006 Jesse Keating - 3.1-6.1 - rebuilt for new gcc4.1 snapshot and glibc changes bc-1.06-19.2 ------------ * Tue Feb 07 2006 Jesse Keating - 1.06-19.2 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 09 2005 Jesse Keating - rebuilt * Mon Nov 21 2005 Thomas Woerner 1.06-19 - fixed rpm macro usage in chengelog (#137800) beagle-0.2.1-1.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 0.2.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes beecrypt-4.1.2-9.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 4.1.2-9.2 - rebuilt for new gcc4.1 snapshot and glibc changes bind-30:9.3.2-3 --------------- * Tue Feb 07 2006 Florian La Roche 30:9.3.2-3 - try supporting without dbus support binutils-2.16.91.0.5-1.1 ------------------------ * Tue Feb 07 2006 Jesse Keating - 2.16.91.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes bison-2.1-1.2 ------------- * Tue Feb 07 2006 Jesse Keating - 2.1-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes bluez-hcidump-1.27-1.2 ---------------------- * Tue Feb 07 2006 Jesse Keating - 1.27-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes bluez-libs-2.22-1.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 2.22-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes bluez-pin-0.24-3.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 0.24-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes bluez-utils-2.22-2.2 -------------------- * Tue Feb 07 2006 Jesse Keating - 2.22-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes bogl-0:0.1.18-11.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 0:0.1.18-11.2 - rebuilt for new gcc4.1 snapshot and glibc changes boost-1.33.1-4.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 1.33.1-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes bootparamd-0.17-24.devel.1 -------------------------- * Tue Feb 07 2006 Jesse Keating - 0.17-24.devel.1 - rebuilt for new gcc4.1 snapshot and glibc changes booty-0.67-1 ------------ * Tue Feb 07 2006 Chris Lumens 0.67-1 - Fix syntax error. bridge-utils-1.0.6-1.1 ---------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.6-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes brltty-3.2-10.2 --------------- * Tue Feb 07 2006 Jesse Keating - 3.2-10.2 - rebuilt for new gcc4.1 snapshot and glibc changes bug-buddy-1:2.13.0-1.1 ---------------------- * Tue Feb 07 2006 Jesse Keating - 1:2.13.0-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes busybox-1:1.01-2.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 1:1.01-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes byacc-1.9-29.2 -------------- * Tue Feb 07 2006 Jesse Keating - 1.9-29.2 - rebuilt for new gcc4.1 snapshot and glibc changes bzip2-1.0.3-2.2 --------------- * Tue Feb 07 2006 Jesse Keating - 1.0.3-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes cadaver-0.22.3-2.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 0.22.3-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes cairo-java-1.0.2-0.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.2-0.1 - rebuilt for new gcc4.1 snapshot and glibc changes ccs-1.0.2-3.2 ------------- * Tue Feb 07 2006 Jesse Keating - 1.0.2-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes cdparanoia-alpha9.8-26.2 ------------------------ * Tue Feb 07 2006 Jesse Keating - alpha9.8-26.2 - rebuilt for new gcc4.1 snapshot and glibc changes cdrdao-1.2.0-1.2.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 1.2.0-1.2.1 - rebuilt for new gcc4.1 snapshot and glibc changes check-0.9.3-4.fc5.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 0.9.3-4.fc5.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Mon Dec 19 2005 Warren Togami 0.9.2-4 - import into FC5 for gstreamer-0.10 * Fri Dec 02 2005 Tom "spot" Callaway 0.9.2-3 - enabled -fPIC to resolve bz 174313 checkpolicy-1.29.1-1 -------------------- * Tue Feb 07 2006 Dan Walsh 1.29.1-1 - Latest upgrade from NSA * Merged sepol_av_to_string patch from Joshua Brindle. * Tue Feb 07 2006 Jesse Keating - 1.28-5.1 - rebuilt for new gcc4.1 snapshot and glibc changes chkconfig-1.3.26-1.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 1.3.26-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes chkfontpath-1.10.0-4.2 ---------------------- * Tue Feb 07 2006 Jesse Keating - 1.10.0-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes cman-1.0.4-0.FC5.1.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.4-0.FC5.1.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 16 2005 Chris Feist - Rebuilt w/ new upstream sources * Fri Dec 09 2005 Jesse Keating - rebuilt compat-db-4.2.52-3.2 -------------------- * Tue Feb 07 2006 Jesse Keating - 4.2.52-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes compat-slang-1.4.9-27.2 ----------------------- * Tue Feb 07 2006 Jesse Keating - 1.4.9-27.2 - rebuilt for new gcc4.1 snapshot and glibc changes control-center-1:2.13.90-6.1 ---------------------------- * Tue Feb 07 2006 Jesse Keating - 1:2.13.90-6.1 - rebuilt for new gcc4.1 snapshot and glibc changes coreutils-5.93-7.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 5.93-7.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Mon Jan 23 2006 Tim Waugh - Fixed chcon(1) bug reporting address (bug #178523). dev86-0.16.17-2.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 0.16.17-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes dlm-1.0.0-9.FC5.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0-9.FC5.1 - rebuilt for new gcc4.1 snapshot and glibc changes emacspeak-23.0-2 ---------------- * Wed Feb 08 2006 Jens Petersen - 23.0-2 - tweak tcl scripts to run tclsh and require Tclx instead, since tclx-8.4 no longer provides /usr/bin/tcl expect-5.43.0-3 --------------- * Tue Feb 07 2006 David Cantrell - 5.43.0-3 - Rebuilt fontconfig-2.3.93.cvs20060207-1 ------------------------------- * Tue Feb 07 2006 Matthias Clasen - 2.3.93.cvs20060207-1 - Newer cvs snapshot - Drop upstreamed patches, pick up some new ones * Tue Feb 07 2006 Jesse Keating - 2.3.93.cvs20060131-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes gjdoc-0.7.7-3 ------------- * Tue Feb 07 2006 Rafael Schloming - 0.7.7-3 - Added ^Z as a whitespace character. * Tue Feb 07 2006 Jesse Keating - 0.7.7-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-icon-theme-2.13.7-2 ------------------------- * Tue Feb 07 2006 Matthias Clasen 2.13.7-2 - Add back some icons that went missing - Fix redhat- symlinks that were broken since FC1 gnome-mount-0.4-0.cvs20060117.2 ------------------------------- * Tue Feb 07 2006 John (J5) Palmieri - 0.4-0.cvs20060117.2 - fix build * Tue Feb 07 2006 Jesse Keating - 0.4-0.cvs20060117.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-power-manager-2.13.5.0.20060207-1 --------------------------------------- * Tue Feb 07 2006 Ray Strode - 2.13.5.0.20060207-1 - pull cvs snapshot from HEAD and drop the patches caillon just added * Tue Feb 07 2006 Christopher Aillon - 2.13.5-3 - Install into the autostart directory - Don't suspend on lid close while on AC power * Tue Feb 07 2006 Jesse Keating - 2.13.5-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-themes-2.13.90-2 ---------------------- * Tue Feb 07 2006 Matthias Clasen - 2.13.90-2 - Remove the hidden patch, since it causes icon themes to not show up in the theme capplet gtk2-2.8.11-6 ------------- * Tue Feb 07 2006 Christopher Aillon 2.8.11-6 - Fix up jkeating's recent %changelog entry to match this spec's style - Make the devel package Require %{version}-%{release} * Tue Feb 07 2006 Jesse Keating 2.8.11-5.1 - rebuilt for new gcc4.1 snapshot and glibc changes hplip-0.9.8-3 ------------- * Tue Feb 07 2006 Tim Waugh 0.9.8-3 - Patchlevel 3. ipsec-tools-0.6.4-1 ------------------- * Tue Feb 07 2006 Harald Hoyer 0.6.4-1 - version 0.6.4 * Tue Feb 07 2006 Jesse Keating - 0.6.3-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes kdegraphics-7:3.5.1-2 --------------------- * Tue Feb 07 2006 Than Ngo 7:3.5.1-2 - apply patch to fix buffer overflow in kpdf, CVE-2006-0301 (#179425) - apply patch to fix gcc warning (#169189) kernel-2.6.15-1.1915_FC5 ------------------------ * Tue Feb 07 2006 Dave Jones - 2.6.16rc2-git3 * Mon Feb 06 2006 Dave Jones - 2.6.16rc2-git2 * Mon Feb 06 2006 David Woodhouse - Update to current softmac/bcm43xx code. kernel-xen-2.6.15-1.43_FC5 -------------------------- * Tue Feb 07 2006 Juan Quintela - fix xen to compile with gcc-4.1. - disable PAE build. - enable debug hypervisor options. * Tue Feb 07 2006 Jesse Keating - rebuilt for new gcc4.1 snapshot and glibc changes * Mon Feb 06 2006 Juan Quintela - merge with rawhide 1.1914. libidn-0.6.2-1 -------------- libselinux-1.29.7-1.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 1.29.7-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Jan 20 2006 Dan Walsh 1.29.7-1 - Upgrade to latest from NSA * Merged install-pywrap Makefile patch from Joshua Brindle. libsemanage-1.5.21-1 -------------------- * Tue Feb 07 2006 Jesse Keating - 1.5.21-1 - Upgrade to latest from NSA * Merged seuser/user_extra support patch from Joshua Brindle. * Merged remote system dbase patch from Ivan Gyurdiev. * Tue Feb 07 2006 Jesse Keating - 1.5.20-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes libsepol-1.11.13-1 ------------------ * Tue Feb 07 2006 Dan Walsh 1.11.12-1 - Upgrade to latest from NSA * Merged seuser/user_extra support patch from Joshua Brindle. * Merged fix patch from Ivan Gyurdiev. * Tue Feb 07 2006 Jesse Keating - 1.11.12-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes mesa-6.4.2-2 ------------ * Tue Feb 07 2006 Mike A. Harris 6.4.2-2 - Added new "glx-utils" subpackage with glxgears and glxinfo (#173510) - Added mesa-6.4.2-dprintf-to-debugprintf-for-bug180122.patch to workaround a Mesa namespace conflict with GNU_SOURCE (#180122) - Added mesa-6.4.2-xorg-server-uses-bad-datatypes-breaking-AMD64-fdo5835.patch as an attempt to fix bugs (#176976,176414,fdo#5835) - Enabled inclusion of the *EXPERIMENTAL UNSUPPORTED* r300 DRI driver on x86, x86_64, and ppc architectures, however the 2D Radeon driver will soon be modified to require the user to manually turn experimental DRI support on with Option "dri" in xorg.conf to test it out and report all X bugs that occur while using it directly to X.Org bugzilla. (#179712) - Use "libOSMesa.so.6.4.0604*" glob in file manifest, to avoid having to update it each upstream release. * Sat Feb 04 2006 Mike A. Harris 6.4.2-1 - Updated to Mesa 6.4.2 - Use "libGLU.so.1.3.0604*" glob in file manifest, to avoid having to update it each upstream release. pam_krb5-2.2.6-1 ---------------- * Mon Feb 06 2006 Nalin Dahyabhai - 2.2.6-1 - add a "krb4_use_as_req" option so that obtaining v4 creds kinit-style can be disabled completely (Hugo Meiland) policycoreutils-1.29.20-1 ------------------------- * Tue Feb 07 2006 Dan Walsh 1.29.20-1 - Update from upstream * Merged seuser/user_extra support patch to semodule_package from Joshua Brindle. * Merged getopt type fix for semodule_link/expand and sestatus from Chris PeBenito. - Fix genhomedircon output * Tue Feb 07 2006 Jesse Keating - 1.29.18-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes redhat-menus-6.6.4-1 -------------------- * Tue Feb 07 2006 Ray Strode - 6.6.4-1 - use gnome icon names for "-Other" menu files * Sun Feb 05 2006 Matthias Clasen - 6.5.4-3 - Add missing requires selinux-doc-1.25.2-1 -------------------- * Tue Feb 07 2006 Dan Walsh 1.25.2-1 - Update to NSA Release version * Updated module report for removal of magic number fields from security structures (in 2.6.16). sysreport-1.4.3-2 ----------------- * Tue Feb 07 2006 Than Ngo 1.4.3-2 - fix broken date string system-config-kickstart-2.6.5-1 ------------------------------- * Tue Feb 07 2006 Chris Lumens 2.6.5-1 - Smarter repo-enabling code (#180097). system-config-lvm-1.0.12-1.0 ---------------------------- * Mon Feb 06 2006 Stanko Kupcevic 1.0.12-1.0 - Under certain conditions, labels might show partially system-config-soundcard-1.2.16-1 -------------------------------- * Wed Feb 01 2006 Martin Stransky 1.2.16-1 - volume control, new look, music (#178124) tix-1:8.4.0-2 ------------- * Tue Feb 07 2006 David Cantrell - 1:8.4.0-2 - Better use of macros in the install and files sections * Mon Feb 06 2006 David Cantrell - 1:8.4.0-1 - Upgraded to tix-8.4.0 udev-084-1 ---------- * Tue Feb 07 2006 Harald Hoyer - 084-1 - version 084 vixie-cron-4:4.1-51.FC5 ----------------------- * Tue Feb 07 2006 Jason Vas Dias - 4.1-51.FC5 - fix bug 180145: provide support for mail in non-ascii charsets xen-3.0-0.20060130.fc5.6 ------------------------ * Tue Feb 07 2006 Jeremy Katz - 3.0-0.20060130.fc5.6 - add a hack to fix VMX guests with video to balloon enough (#180375) * Tue Feb 07 2006 Jeremy Katz - 3.0-0.20060130.fc5.5 - fix build for new udev * Tue Feb 07 2006 Jeremy Katz - 3.0-0.20060130.fc5.4 - patch from David Lutterkort to pass macaddr (-m) to xenguest-install - rework xenguest-install a bit so that it can be used for creating fully-virtualized guests as well as paravirt. Run with --help for more details (or follow the prompts) - add more docs (noticed by Andrew Puch) xmltex-20020625-7 ----------------- * Tue Feb 07 2006 Tim Waugh 20020625-7 - Fix xmltex symlink (-> latex) (bug #168728). xorg-x11-server-1.0.1-5 ----------------------- * Tue Feb 07 2006 Mike A. Harris 1.0.1-5 - Updated "BuildRequires: mesa-source >= 6.4.2-2" to get fix for (#176976) * Mon Feb 06 2006 Mike A. Harris 1.0.1-4 - Fix brown paper bag error introduced in rpm post script in 1.0.1-4. * Mon Feb 06 2006 Mike A. Harris 1.0.1-3 - Added xorg-x11-server-1.0.1-composite-fastpath-fdo4320.patch with changes suggested by ajax to fix (fdo#4320). - Cosmetic cleanups to satiate the banshees. Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 tkinter - 2.4.2-3.i386 requires libtix8.1.8.4.so Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs tkinter - 2.4.2-3.ia64 requires libtix8.1.8.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- ccs-devel - 1.0.2-3.2.ppc requires ccs = 0:1.0.2-3.2 gulm - 1.0.4-2.FC5.1.ppc requires ccs tkinter - 2.4.2-3.ppc requires libtix8.1.8.4.so Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 tkinter - 2.4.2-3.ppc64 requires libtix8.1.8.4.so()(64bit) Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.4-2.s390 requires kernel >= 0:2.6.9-11 tkinter - 2.4.2-3.s390 requires libtix8.1.8.4.so Broken deps for s390x ---------------------------------------------------------- libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) systemtap - 0.5.4-2.s390x requires kernel >= 0:2.6.9-11 tkinter - 2.4.2-3.s390x requires libtix8.1.8.4.so()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 tkinter - 2.4.2-3.x86_64 requires libtix8.1.8.4.so()(64bit) From mharris at mharris.ca Wed Feb 8 09:45:06 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Wed, 08 Feb 2006 04:45:06 -0500 Subject: Request for testers: Video hardware autodetection In-Reply-To: References: Message-ID: <43E9BDA2.2060001@mharris.ca> Jason Dravet wrote: > I would love to test this new autodection setup. However when I run > system-config-display it crashes. I opened a bugzilla about this over > two months ago and no work has been done to fix this problem. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174686 Unfortunately, I don't think there is any active development/maintenance happening to system-config-display currently. There are tonnes of bugs filed against it, but there don't appear to be CVS commits very often, etc. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 8 09:48:22 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 8 Feb 2006 10:48:22 +0100 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <43E968A0.7060609@uindy.edu> References: <1139006387.2652.29.camel@bree.local.net> <1139014200.2863.65.camel@yoda.loki.me> <43E48DDD.4060508@vip.hr> <200602041255.23869.lamont@gurulabs.com> <43E5095E.3060804@mharris.ca> <43E6763A.8050509@uindy.edu> <43E7186E.7050307@redhat.com> <1139243683.3188.14.camel@yoda.loki.me> <20060206195913.GB30359@redhat.com> <43E968A0.7060609@uindy.edu> Message-ID: <20060208104822.414b8c88@python2> D Canfield wrote : > Resume now works on my T43 after I comment out the DRI option in > xorg.conf. I have an ATI chipset. > > Only other resume problem is that NetworkManager doesn't know that I > have any network interfaces after a resume. I can restart the network > (through init.d), but NM still doesn't see any interfaces. The NIC module you use maybe doesn't support resume. I know that my Dell X1 laptop has that problem with it's NIC as it uses the tg3 module, and does work when the kernel is patched (a patch found on lkml, maybe in recent 2.6 now, dunno)... luckily ipw2200 and bluetooth work perfectly. In all cases, "dmesg" should give you an idea about what's going wrong with your NIC after resume, and it might be worth bugzilla'ing it. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.15-1.1830_FC4 Load : 0.31 0.37 0.38 From mharris at mharris.ca Wed Feb 8 09:49:10 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Wed, 08 Feb 2006 04:49:10 -0500 Subject: use of downloaded SRPMS In-Reply-To: <43E8F8C5.60900@BitWagon.com> References: <43E8F8C5.60900@BitWagon.com> Message-ID: <43E9BE96.7070200@mharris.ca> John Reiser wrote: > On Fri, 03 Feb 2006 05:36:52 -0500 Mike A. Harris asked: > >>1) How many people actually download the SRPMS disk images? >> >>2) How many people actually really use them for anything? > > > I download the SRPMS for RHEL, and for non-test releases of Fedora Core. > I frequently modify and rebuild (on both x86 and x86_64): > kernel (perfctr extension) > glibc (find and fix the bugs) > and sometimes > gcc (dwarf2 unwind) > wvdial,minicom,etc. (dialup seems to be a forgotten > stepchild, but it's still required) > > I also burn a DVD of the SRPMS, and keep it as a defense against > possible future license changes which might restrict my activities > with respect to then-readily-available sources. You downloaded the SRPM CDROM/DVD image and burned it, or you downloaded the SRPMS directory from the ftp site? -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Wed Feb 8 10:13:14 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Wed, 08 Feb 2006 05:13:14 -0500 Subject: nothing from buildsys? In-Reply-To: <20060207191930.GB5319@ti64.telemetry-investments.com> References: <43E1E0BE.2080908@adslpipe.co.uk> <5256d0b0602020239s3aa68266p37346bfc4d493c12@mail.gmail.com> <43E32AAE.2030703@mharris.ca> <5256d0b0602030211k2631d39cgbbc767d5fb29fbcd@mail.gmail.com> <43E33244.7080605@mharris.ca> <20060207191930.GB5319@ti64.telemetry-investments.com> Message-ID: <43E9C43A.7050404@mharris.ca> Bill Rugolsky Jr. wrote: > On Fri, Feb 03, 2006 at 05:36:52AM -0500, Mike A. Harris wrote: > >>As a total side-question though, just for personal curiousity... >> >>1) How many people actually download the SRPMS disk images? > > > I routinely download the SRPMS, though I grab them from the SRPMS/ > directories on the servers. Not much interest in the disk images, > since after a few weeks there are dozens if not hundreds of updates. Yeah, that's why I am of the general mindset that the SRPMS disks are kindof useless for the most part. They are perhaps useful for archival of the exact source of the binary disks in case someone really really needs that down the line and wants to ensure they have a local copy. But for most practical purposes, IMHO at least, the SRPMS dir on the ftp servers is much more useful. ;) > > >>2) How many people actually really use them for anything? > > I keep SRPMS for several reasons: I keep SRPMS for many reasons too. I get them from our internal server (porkchop), or our CVS server, or from our ftp servers though. I just wondered what reasons people would download the SRPMS DVD ISO image and burn it to a disk. SRPMS are useful, no question, but how useful is a set of outdated SRPMS in a week or two? ;o) -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From andy at warmcat.com Wed Feb 8 10:13:25 2006 From: andy at warmcat.com (Andy Green) Date: Wed, 08 Feb 2006 10:13:25 +0000 Subject: OLPC + Fedora = ??? In-Reply-To: <1139369574.3279.34.camel@daxter.boston.redhat.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> Message-ID: <43E9C445.2060500@warmcat.com> David Zeuthen wrote: >>Well glad to hear it, I hope these rather fundamental questions will >>still be in scope by then. > Our current thinking (and code) revolves partly around making it easier > to build derived lean distributions based on Fedora Core. All this > includes fixing a few obvious and not-so-obvious things in Core; it > includes lots of thinking about distribution and updates in scenarios > that the OLPC project targets (e.g. millions of users, extremely low > admin/user ratios, think appliance); it includes thoughts about how lock > down and provide a secure OS out of the box; it includes thinking about > how to fit this in almost no space with very limited RAM and worse.. no > swap; it includes thinking about how to easily enable application > developers and other stake holders to participate... and a whole bunch > of other stuff too.. These are the preoccupations daily dealt with by embedded developers. I'm sure there are plenty of capable embedded devs in Redhat still, but I take from your answer that this is going to stay Redhat internal until it is set in stone. That's probably not so bad generally except that my suggestions are about the fundamentals of it that will be decided by then. I guess I did the suggestion action. Core as it is implies quite a heavy demand on RAM, flash and CPU horsepower. I really do think what I said before about triage modifying the machine spec stands a good chance to happen (given that commitment is apparently being requested for money for a machine at a specific price point, and the easiest fat to trim is the CPU and memory), or, if not, the machine may grossly fail to meet its price point[1]. And that has a lot of ramifications on how to come at it that start to diverge from a vision of Fedora Tiny or whatever still looking much like what you get with today's minimal Fedora resolved packageset (especially in installed storage footprint). > It's also useful to keep in mind that the software side of the OLPC > project is larger than the bits Red Hat will provide - there's a bunch Well I can't usefully comment on the usermode stuff. > Anyway, it's probably not useful to start a huge thread here about these > high-level thoughts (read: no need to reply)... First of all we need a I will be interested to see what you come up with. -Andy [1] Reality check: how much would a PDA cost with those features, CPU and Memory in today's prices, minus say 60% for manufacturer and retailer margin and extra goodwill? An HP IPAQ hx4700 with 64MB SDRAM and 128MB flash, wifi etc, is GBP337 ($586.38) http://www.dabs.com/ProductView.aspx?Quicklinx=380L&CategorySelectedId=11107&PageMode=1&NavigationKey=11107,41689&v=2#infoarea If we accept that base price despite no meeting the featureset then we still reach $234 with our -60% modifier. -70% gives $175. They need a -83% modifier to reach $100. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From mharris at mharris.ca Wed Feb 8 09:14:49 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Wed, 08 Feb 2006 04:14:49 -0500 Subject: [Fwd: Re: rawhide report: 20060207 changes] Message-ID: <43E9B689.6050203@mharris.ca> Every time I post to the fedora lists lately, I am getting an autoresponder antispam message back from one of the list members: eorgan945.sspam at uol.com.br This is completely irresponsible behaviour, and bad netiquette. The way I see it, there are 3 choices: 1) This person immediately disables this antispam confirmation bot and apologizes to the mailing list(s), promising to never do this again. or 2) The list administrators kindly remove the person's address from the subscription list, transfering it to the permanent ban list. If necessary, blocking the entire domain if the problem returns (uol.com.br). or 3) I for one, will unsubscribe from all of the fedora lists, simply to avoid this nonesense. I get 300 spam per day, and certainly don't need someone adding to it foolishly on subscription-only mailing lists. If #2 becomes necessary, and the individual can not be identified, I suggest blocking uol.com.br at the IP filter level on Red Hat border routers. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. -------------- next part -------------- An embedded message was scrubbed... From: AntiSpam UOL Subject: RE: Re: rawhide report: 20060207 changes Date: Tue, 7 Feb 2006 10:22:48 -0200 (BRST) Size: 7406 URL: From bart.vanbrabant at zoeloelip.be Wed Feb 8 10:23:03 2006 From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant) Date: Wed, 08 Feb 2006 11:23:03 +0100 Subject: rawhide report: 20060208 changes In-Reply-To: <200602080840.k188efVd027329@porkchop.devel.redhat.com> References: <200602080840.k188efVd027329@porkchop.devel.redhat.com> Message-ID: <43E9C687.7030003@zoeloelip.be> > fontconfig-2.3.93.cvs20060207-1 > ------------------------------- > * Tue Feb 07 2006 Matthias Clasen - 2.3.93.cvs20060207-1 > - Newer cvs snapshot > - Drop upstreamed patches, pick up some new ones > > * Tue Feb 07 2006 Jesse Keating - 2.3.93.cvs20060131-3.1 > - rebuilt for new gcc4.1 snapshot and glibc changes > fontconfig killed all mozilla based products (mozilla, firefox and thunderbird). The fonts were replaced by some strange font. Reinstalling the previous fontconfig version fixed the problem. gr, Bart -- Bart Vanbrabant PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From gnomeuser at gmail.com Wed Feb 8 10:28:34 2006 From: gnomeuser at gmail.com (David Nielsen) Date: Wed, 08 Feb 2006 11:28:34 +0100 Subject: [Fwd: Re: rawhide report: 20060207 changes] In-Reply-To: <43E9B689.6050203@mharris.ca> References: <43E9B689.6050203@mharris.ca> Message-ID: <1139394515.1898.0.camel@price.stavtrup-st.dk> ons, 08 02 2006 kl. 04:14 -0500, skrev Mike A. Harris: > Every time I post to the fedora lists lately, I am getting an > autoresponder antispam message back from one of the list members: > > eorgan945.sspam at uol.com.br So annoying it has it's own wiki page. http://fedoraproject.org/wiki/UOL - David -- Obligatory shameless blog plug - the GNOME commentary located at: www.lovesunix.net/blog From che666 at gmail.com Wed Feb 8 10:29:57 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Wed, 8 Feb 2006 11:29:57 +0100 Subject: mock + ccache? (was Re: nothing from buildsys?) In-Reply-To: <1139331613.27273.17.camel@weasel.turre.laiskiainen.org> References: <43E1E0BE.2080908@adslpipe.co.uk> <5256d0b0602020239s3aa68266p37346bfc4d493c12@mail.gmail.com> <43E1F427.3050701@reub.net> <43E32D5A.5050907@mharris.ca> <20060203164535.GA20256@osiris.silug.org> <1139331613.27273.17.camel@weasel.turre.laiskiainen.org> Message-ID: 2006/2/7, Panu Matilainen : > On Fri, 2006-02-03 at 10:45 -0600, Steven Pritchard wrote: > > On Fri, Feb 03, 2006 at 05:15:54AM -0500, Mike A. Harris wrote: > > > If you've got a 1.5Ghz CPU or faster, and install "ccache" from Fedora > > > Extras, your machine will build pretty much any package faster than > > > our buildsystem. ;o) > > > > That reminds me... Has anyone ever tried to tie mock and ccache > > together somehow? It seems like that would speed up repeated build > > attempts noticably. > > At least with mach it works nicely, just install ccache into the chroot > and it'll get used. I don't remember if mock recreates the chroot from > scratch each time you build something - if not it should be just a > matter of installing ccache in the root (via buildgroup or manually), > otherwise it'll get more tricky. thats the default behaviour of mock actually. theres a noclean option though you can pass to it. regards, Rudolf Kastl > > - Panu - > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From mharris at mharris.ca Wed Feb 8 10:32:17 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Wed, 08 Feb 2006 05:32:17 -0500 Subject: [Fwd: Re: rawhide report: 20060207 changes] In-Reply-To: <43E9B689.6050203@mharris.ca> References: <43E9B689.6050203@mharris.ca> Message-ID: <43E9C8B1.7040707@mharris.ca> Mike A. Harris wrote: > Every time I post to the fedora lists lately, I am getting an > autoresponder antispam message back from one of the list members: > > eorgan945.sspam at uol.com.br > > This is completely irresponsible behaviour, and bad netiquette. > > The way I see it, there are 3 choices: > > 1) This person immediately disables this antispam confirmation > bot and apologizes to the mailing list(s), promising to never > do this again. > > or > > 2) The list administrators kindly remove the person's address > from the subscription list, transfering it to the permanent > ban list. If necessary, blocking the entire domain if the > problem returns (uol.com.br). > > or > > 3) I for one, will unsubscribe from all of the fedora lists, > simply to avoid this nonesense. I get 300 spam per day, > and certainly don't need someone adding to it foolishly > on subscription-only mailing lists. > > > If #2 becomes necessary, and the individual can not be identified, > I suggest blocking uol.com.br at the IP filter level on Red Hat > border routers. Since posting, I've been informed of the problem at a deeper level, and of the FAQ on the Fedora Wiki, and the problems involved in trying to do option #2. In the mean time, a 4th option presented itself: 4) Having uol.com.br blacklisted via the MTA by the admin of my domain. It'd be cool if that could be done on the redhat.com domain also. mgalgoci? -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From bbbush.yuan at gmail.com Wed Feb 8 10:37:49 2006 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Wed, 8 Feb 2006 18:37:49 +0800 Subject: propozition of specs cleanups In-Reply-To: <1139052496.6900.29.camel@kloczek01.pracownicy.zie> References: <1138959257.25983.84.camel@kloczek01.pracownicy.zie> <43E3302C.2070602@mharris.ca> <1138965417.25983.133.camel@kloczek01.pracownicy.zie> <43E34156.9030402@fedoraproject.org> <1138968719.25983.142.camel@kloczek01.pracownicy.zie> <43E34B61.9000809@fedoraproject.org> <1138985448.25983.182.camel@kloczek01.pracownicy.zie> <43E48898.1040201@fedoraproject.org> <1139052496.6900.29.camel@kloczek01.pracownicy.zie> Message-ID: <76e72f800602080237p19cf0d97n@mail.gmail.com> 2006/2/4, Tomasz K?oczko : > > and .. interesting: > $ grep BuildRoot: *spec | awk '{print $2}' | sort | grep > '%{_tmppath}/%{name}-%{version}-%{release}-root-%\(%{__id_u} -n\)' | wc > -l > 0 > > - Parallel make > I think these rules are applied very well in fedora extras but not in core since the rpm spec files in FE are always come from the template file of "fedora-rpmdevtools" while the core rpms are almostly not from FE. -- bbbush (To the beautiful PLD logo) ^_^ From bart.vanbrabant at zoeloelip.be Wed Feb 8 10:43:40 2006 From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant) Date: Wed, 08 Feb 2006 11:43:40 +0100 Subject: Ugly X11 pointers Message-ID: <43E9CB5C.4060306@zoeloelip.be> Hello, A few weeks back in rawhide only X11 cursors worked. This was fixed same time later. I re?nstalled from rawhide a few days back and now I only see the X11 cursors. If I select an other cursor theme in the Mouse dialog under preferences I see that cursor theme for new programs but after a new login the ugly X11 cursors are back. Should this be filled as a bug report? gr, Bart -- Bart Vanbrabant PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From nicolas.mailhot at laposte.net Wed Feb 8 10:59:26 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 8 Feb 2006 11:59:26 +0100 (CET) Subject: [Fwd: Re: rawhide report: 20060207 changes] In-Reply-To: <43E9C8B1.7040707@mharris.ca> References: <43E9B689.6050203@mharris.ca> <43E9C8B1.7040707@mharris.ca> Message-ID: <49186.192.54.193.35.1139396366.squirrel@rousalka.dyndns.org> Le Mer 8 f?vrier 2006 11:32, Mike A. Harris a ?crit : > Mike A. Harris wrote: > Since posting, I've been informed of the problem at a deeper level, > and of the FAQ on the Fedora Wiki, and the problems involved in > trying to do option #2. In the mean time, a 4th option presented > itself: Another solution is to put descent email filtering on the lists or on your system. These posts never passed my postfix+amavisd-new+clamav+sa filter, I've been posting on the lists for months and only learn today of the problem. Smart mail filtering rulez Regards, -- Nicolas Mailhot From mharris at mharris.ca Wed Feb 8 11:37:53 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Wed, 08 Feb 2006 06:37:53 -0500 Subject: [Fwd: Re: rawhide report: 20060207 changes] In-Reply-To: <200602080620.14340.sgrubb@redhat.com> References: <43E9B689.6050203@mharris.ca> <43E9C8B1.7040707@mharris.ca> <200602080620.14340.sgrubb@redhat.com> Message-ID: <43E9D811.7060204@mharris.ca> Steve Grubb wrote: > On Wednesday 08 February 2006 05:32, Mike A. Harris wrote: > >>4) Having uol.com.br blacklisted via the MTA by the admin of my >> domain. > > > There's another option: > > 5) Delete everyone out of the mail list and let everybody re-enroll. That wouldn't solve anything. Some people would just not bother resubscribing due to laziness or not caring. Those that would resubscribe, certainly would not preclude the problematic person, so nothing would be gained. The majority of list subscribers would be annoyed with no real world gain. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From n0dalus+redhat at gmail.com Wed Feb 8 11:39:49 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Wed, 8 Feb 2006 22:09:49 +1030 Subject: [Fwd: Re: rawhide report: 20060207 changes] In-Reply-To: <200602080620.14340.sgrubb@redhat.com> References: <43E9B689.6050203@mharris.ca> <43E9C8B1.7040707@mharris.ca> <200602080620.14340.sgrubb@redhat.com> Message-ID: <6280325c0602080339x63857c54qee401bf6d85eabed@mail.gmail.com> On 2/8/06, Steve Grubb wrote: > On Wednesday 08 February 2006 05:32, Mike A. Harris wrote: > > 4) Having uol.com.br blacklisted via the MTA by the admin of my > > domain. > > There's another option: > > 5) Delete everyone out of the mail list and let everybody re-enroll. > Can't we just send an email to each person like this?: To: fedora-devel-list at redhat.com Subject: Automated response checker $unique_number Hi, Unfortunately someone on the Fedora development list is redirecting their emails to a domain that sends an automated response email to any unknown senders whenever they post to the list. The only way to find the address responsible is to send an email to everyone with a unique subject line. We apologize that it has come to this, and invite you to consider that while you may be slightly inconvinienced by this single email, other people are suffering a constant inconvinience because of this issue. Yours sincerely, Mailing list staff. Of course it would need to be sent from a server/address that currently receives the uol responses (I know my Gmail account doesn't get them.) n0dalus. From mharris at mharris.ca Wed Feb 8 12:01:32 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Wed, 08 Feb 2006 07:01:32 -0500 Subject: [Fwd: Re: rawhide report: 20060207 changes] In-Reply-To: <6280325c0602080339x63857c54qee401bf6d85eabed@mail.gmail.com> References: <43E9B689.6050203@mharris.ca> <43E9C8B1.7040707@mharris.ca> <200602080620.14340.sgrubb@redhat.com> <6280325c0602080339x63857c54qee401bf6d85eabed@mail.gmail.com> Message-ID: <43E9DD9C.1050803@mharris.ca> n0dalus wrote: > On 2/8/06, Steve Grubb wrote: > >>On Wednesday 08 February 2006 05:32, Mike A. Harris wrote: >> >>>4) Having uol.com.br blacklisted via the MTA by the admin of my >>>domain. >> >>There's another option: >> >>5) Delete everyone out of the mail list and let everybody re-enroll. >> > > > Can't we just send an email to each person like this?: > > To: fedora-devel-list at redhat.com > Subject: Automated response checker $unique_number That's already been done by someone, who has indicated they weren't able to determine who it was. I think it is just someone who is intentionally causing trouble for everyone on the list, and is deriving great pleasure from reading our emails, knowing full well that they are irritating everyone. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From nigel.metheringham at dev.intechnology.co.uk Wed Feb 8 12:13:09 2006 From: nigel.metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Wed, 08 Feb 2006 12:13:09 +0000 Subject: [Fwd: Re: rawhide report: 20060207 changes] In-Reply-To: <43E9D811.7060204@mharris.ca> References: <43E9B689.6050203@mharris.ca> <43E9C8B1.7040707@mharris.ca> <200602080620.14340.sgrubb@redhat.com> <43E9D811.7060204@mharris.ca> Message-ID: <1139400789.7699.18.camel@localhost.localdomain> I'm a bit reluctant to join a discussion that can have no useful outcome... but I guess I may as well make it clear that we can't fix this problem unless someone can intimidate uol.com.br fix their policy The major problem is that the idiots running the domain send their antispam confirmation messages to the From: header address rather than the envelope sender address - this particularly fouls up in the case of mailing lists where the From: header is very different to the envelope sender. If you really have to respond to the From: header (and I'd maintain that since you are sending a message disposition response you should be sending it to the envelope address) then you should at least honour reply-to (which would have fixed the problem in this case). So the proposed solutions so far... > 1) This person immediately disables this antispam confirmation Good, but it won't happen. > 2) The list administrators kindly remove the person's address Lucky administrators who get to play whack-a-mole when you can bet they don't even see the moles themselves but have to be told about them by other folks... Blocking them from subscribing runs you into a arms race between them and us - people will subscribe with aliased addresses and the like. > 3) I for one, will unsubscribe from all of the fedora lists, Actually thats the most effective solution - but its unacceptable. > 4) Having uol.com.br blacklisted via the MTA by the admin of my domain That only moves the problem around a bit - it solves it for a few people but leaves the rest of the world with the same problem. If done on the RH system it might help because anyone from that domain won't be able to confirm their subscription (although you may be able to get round that fairly easily). > 5) Delete everyone out of the mail list and let everybody re-enroll. Well that would clean the lists out... but they would resubscribe. Several others who are more valuable to us would not resubscribe. > 6) Probe for the idiot concerned. This just leads you back to (2). I have done that once in a case where there was a very active autoresponder on a list, but its last resort stuff. Oddly enough it appears that some people get these replies, and others don't - for example I see no evidence of any connections to my mail systems from uol.br.com other than a couple of drive by spammers on dialup. I certainly haven't got the confirmations - not even failed attempts to send me confirmations. The only sensible way to fix this is to deal with uol.com.br and get them to make their spam control stuff half sane - or go the no spam route and disconnect from the net. Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From fedora at camperquake.de Wed Feb 8 12:39:36 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 8 Feb 2006 13:39:36 +0100 Subject: [Fwd: Re: rawhide report: 20060207 changes] In-Reply-To: <1139400789.7699.18.camel@localhost.localdomain> References: <43E9B689.6050203@mharris.ca> <43E9C8B1.7040707@mharris.ca> <200602080620.14340.sgrubb@redhat.com> <43E9D811.7060204@mharris.ca> <1139400789.7699.18.camel@localhost.localdomain> Message-ID: <20060208133936.3427583a@dhcp05.addix.net> Hi. On Wed, 08 Feb 2006 12:13:09 +0000, Nigel Metheringham wrote: > The major problem is that the idiots running the domain send their > antispam confirmation messages to the From: header address rather than > the envelope sender address - this particularly fouls up in the case > of mailing lists where the From: header is very different to the > envelope sender. What is the use of sending confirmation messages to an address which is handled exclusively by machines? From nigel.metheringham at dev.intechnology.co.uk Wed Feb 8 12:48:34 2006 From: nigel.metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Wed, 08 Feb 2006 12:48:34 +0000 Subject: [Fwd: Re: rawhide report: 20060207 changes] In-Reply-To: <20060208133936.3427583a@dhcp05.addix.net> References: <43E9B689.6050203@mharris.ca> <43E9C8B1.7040707@mharris.ca> <200602080620.14340.sgrubb@redhat.com> <43E9D811.7060204@mharris.ca> <1139400789.7699.18.camel@localhost.localdomain> <20060208133936.3427583a@dhcp05.addix.net> Message-ID: <1139402914.7699.26.camel@localhost.localdomain> On Wed, 2006-02-08 at 13:39 +0100, Ralf Ertzinger wrote: > Hi. > > On Wed, 08 Feb 2006 12:13:09 +0000, Nigel Metheringham wrote: > > > The major problem is that the idiots running the domain send their > > antispam confirmation messages to the From: header address rather than > > the envelope sender address - this particularly fouls up in the case > > of mailing lists where the From: header is very different to the > > envelope sender. > > What is the use of sending confirmation messages to an address which > is handled exclusively by machines? Absolutely none at all... the whole thing is pretty pointless. Basically you should take a mailing list as a whole - allow all of the content or none of it. That would happen for them automatically if they sent confirmation requests to the envelope sender .... the fact that no one would bother to reply to them is their problem, as is the fact that the MLM would unsubscribe them if they keep sending (effective) bounce messages to it. Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From brugolsky at telemetry-investments.com Wed Feb 8 13:12:20 2006 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Wed, 8 Feb 2006 08:12:20 -0500 Subject: caution with latest kernel + glibc In-Reply-To: <43E518BA.3010207@redhat.com> References: <43E518BA.3010207@redhat.com> Message-ID: <20060208131220.GA7056@ti64.telemetry-investments.com> On Sat, Feb 04, 2006 at 01:12:26PM -0800, Ulrich Drepper wrote: > Those who are running the current rawhide kernel and glibc (and > coreutils or those trying to compile glibc for themselves) might find > that their kernel locks up. One bug in this area (I think there is more > than one) is fixed by the patch in > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178558 > > The 1909 kernel and later will likely have the patch. For now it might > be best to use glibc-2.3.90-30 and nothing later or alternatively live > with the lockups for today. The fixed kernel is hopefully in tomorrow's > rawhide. 1909 x86_64 still locked up on my Tyan 2885 SMP, but 1914 has been up ten hours and has shuffled more than 300GB on disk using cpio (local) and rsync (remote). Prior to 1914, recent kernels would kill the box in 10-200 minutes under much lighter load (like browsing the web or typing in a terminal). Thanks for the warning. -Bill From webmaster at margo.bijoux.nom.br Wed Feb 8 13:12:13 2006 From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo) Date: Wed, 08 Feb 2006 11:12:13 -0200 Subject: [Fwd: Re: rawhide report: 20060207 changes] In-Reply-To: <1139400789.7699.18.camel@localhost.localdomain> References: <43E9B689.6050203@mharris.ca> <43E9C8B1.7040707@mharris.ca> <200602080620.14340.sgrubb@redhat.com> <43E9D811.7060204@mharris.ca> <1139400789.7699.18.camel@localhost.localdomain> Message-ID: <43E9EE2D.7040809@margo.bijoux.nom.br> Nigel Metheringham wrote: > The only sensible way to fix this is to deal with uol.com.br and get > them to make their spam control stuff half sane - or go the no spam > route and disconnect from the net. > If only Uol would listen.. I've sent a few complaints already to them about these e-mails when they first appeared on fedora-list but so far, I haven't received any answer. Maybe if they start receiving several complaints about the same person they may do something... Or they just keep their position of "we're one of the biggest ISPs in Brazil and we don't need to bow to anyone's wishes to block one of our users". I'll probably meet this weekend with one guy who has worked there and may still have some contacts with the sysadmins. Maybe this way we can make them aware of their crappy challenge-response mess.. -- Pedro Macedo From mailinglists at erwinrol.com Wed Feb 8 13:31:23 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 08 Feb 2006 14:31:23 +0100 Subject: Java on x86_64 Message-ID: <1139405483.8135.85.camel@xpc.home.erwinrol.com> Is there any hope the java GC bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179228 will be solved in the near future. Since it prevents the use of pretty much every java application, so those applications aren't being tested anymore. And most java applications, like eclipse, are huge and certainly could use every minute of testing. - Erwin From gilboad at gmail.com Wed Feb 8 13:41:59 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 08 Feb 2006 15:41:59 +0200 Subject: Testing Xen. Some quick questions. In-Reply-To: <1139368548.2603.35.camel@dragon.sys.intra> References: <1139368548.2603.35.camel@dragon.sys.intra> Message-ID: <1139406119.25572.32.camel@gilboa-work-dev> On Wed, 2006-02-08 at 12:15 +0900, Naoki wrote: > http://fedoraproject.org/wiki/FedoraXenQuickstart & > http://fedoraproject.org/wiki/FedoraXenQuickstartFC5 > > I'm just running through these instructions as a reference for my Xen3 > tests on rawhide and all is going pretty well. > > I have a test domain (but can't alter the number of VCPUs for some > reason but that's another story) and I'm wondering. Rather than the > pretty ugly system of either : > > Make an image file. > Mount. > yum --installroot=blah groupinstall x y z > Configure. > > Or the much better system of /usr/sbin/xenguest-install.py, > > Is there a simple way to fake a netboot so I can use my existing > kickstart scripts and build OS instances the same way I would with > normal physical hardware? > It would be nice to have my hypervisor instance running dhcp + apache > and do localhost kickstart network installs. (I know this has been asked times and times before.) but... What's the current status of Xen/x86_64? Second, considering the fact that rawhide/x86_64 still doesn't have kernel-xen and the pending release of test3, what are the chances of Xen/x86_64 making it's way into FC5? Any chance it'll make it into test3? (I assume that past test3, only bug fixes will be introduced until FC5-release) Gilboa From ihok at hotmail.com Wed Feb 8 13:46:52 2006 From: ihok at hotmail.com (Jack Tanner) Date: Wed, 08 Feb 2006 08:46:52 -0500 Subject: gnome-bluetooth, openobex, etc. Message-ID: Rawhide is behind on openobex (latest is 1.1, rawhide includes 1.0.1). Bugzilla, or would it confuse gnome-bluetooth? From dcbw at redhat.com Wed Feb 8 14:24:40 2006 From: dcbw at redhat.com (Dan Williams) Date: Wed, 08 Feb 2006 09:24:40 -0500 Subject: OLPC + Fedora = ? In-Reply-To: <1139384578.3579.39.camel@ender> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> <1139384082.15809.2.camel@rousalka.dyndns.org> <1139384578.3579.39.camel@ender> Message-ID: <1139408681.2584.9.camel@dhcp83-115.boston.redhat.com> On Tue, 2006-02-07 at 23:42 -0800, Jesse Keating wrote: > On Wed, 2006-02-08 at 08:34 +0100, Nicolas Mailhot wrote: > > So work through Fedora Extras. Please do not segregate OLPC packages > > where other projects can not benefit. > > Some of the content that goes into OLPC may not be appropriate for > Extras. Things are still being worked out, please have patience. That said, these are likely to be secondary tools and administrative apps (like tools for generating the images that you flash the machines with). Most of the work will either be done upstream or in Core itself, since it's usually just config changes (i.e. kernel), or splitting up packages to reduce dependencies. It's slightly unclear how this will work exactly, but it usually won't result in _code_ changes. Just packaging ones. Any real code changes are going to be done upstream if possible; the kernel needs some work for the Geode companion chip, X.org needs heavy fixing of the 'nsc' driver, etc. But none of this has to live _only_ in Core or Extras. That's stupid. OLPC stuff is going to happen upstream as much as possible. That also lets _anyone_, not just Red Hat people, contribute as much as they can. And that's fundamental to the project in the long run. Lots of this work is generic anyway and simply consists of breaking stupid dependencies and slimming packages down. Not too many people are going to be able to physically have the OLPC hardware, since it's going to governments and schools (and isn't on sale to the public). But since so much of the work is widely applicable, that's not much of an issue. Dan From alan at redhat.com Wed Feb 8 15:26:59 2006 From: alan at redhat.com (Alan Cox) Date: Wed, 8 Feb 2006 10:26:59 -0500 Subject: [Fwd: Re: rawhide report: 20060207 changes] In-Reply-To: <1139400789.7699.18.camel@localhost.localdomain> References: <43E9B689.6050203@mharris.ca> <43E9C8B1.7040707@mharris.ca> <200602080620.14340.sgrubb@redhat.com> <43E9D811.7060204@mharris.ca> <1139400789.7699.18.camel@localhost.localdomain> Message-ID: <20060208152659.GA2093@devserv.devel.redhat.com> On Wed, Feb 08, 2006 at 12:13:09PM +0000, Nigel Metheringham wrote: > > 4) Having uol.com.br blacklisted via the MTA by the admin of my domain > > That only moves the problem around a bit - it solves it for a few people > but leaves the rest of the world with the same problem. If done on the > RH system it might help because anyone from that domain won't be able to > confirm their subscription (although you may be able to get round that > fairly easily). Just block Brazil. That'll create an incentive for Brazillians to fix uol.com.br ;) (Not thats not a totally serious suggestion) Alan From n0dalus+redhat at gmail.com Wed Feb 8 15:37:06 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Thu, 9 Feb 2006 02:07:06 +1030 Subject: [Fwd: Re: rawhide report: 20060207 changes] In-Reply-To: References: <43E9B689.6050203@mharris.ca> <6280325c0602080339x63857c54qee401bf6d85eabed@mail.gmail.com> <43E9DD9C.1050803@mharris.ca> <200602080748.56664.sgrubb@redhat.com> <1139403512.4112.17.camel@tjikkun.dyndns.org> <1139407165.19396.12.camel@spikehome.5797net.local> Message-ID: <6280325c0602080737y46b4911aga2637319bb935dfd@mail.gmail.com> On 2/9/06, Miles Lane wrote: > On Wed, 2006-02-08 at 13:58 +0100, Sander Hoentjen wrote: > [...] > > I vote for the clear/resubscribe option. > > Me to. If people can't be bothered to resubscribe, how much are they > likely to contribute to Fedora? Not much, I bet. > I disagree. I am on the mailing lists of several open source projects, and every now and then I will mark unread emails on one or two of them as read. I don't have time to read all the emails, but it's great to have them in my archive for searching, and every now and then I see a topic that I can contribute to. If one of the mailing lists that I'm currently not reading got one of these resubscribe requests I could easily fail to notice it -- that doesn't mean I'm not likely to contribute to their project every now and then. I think the best way is to just send an email to everyone. I have been on the list for several months now and I have never gotten any automated email like the one described earlier. This could be because I'm not in the public subscriber list. Or perhaps the email wasn't To: fedora-devel (because the responsible person may have a filter to only forward some emails) or maybe it was sent in a way that wouldn't have usually gotten a challenge from the UOL server. Someone asked why not everyone gets the emails. I am guessing it's because some domains (like gmail, hotmail, etc) are whitelisted on their server. I think a mass unique email is the best way. It would use just as many emails as sending a resubscribe request to everyone, and it would be far more effective at finding the person responsible (if constructed correctly). For all we know it could be that someone's box has been hacked and their mail config files have been set to forward all their mail to this uol account. If the forwarding is accidental or through some other circumstances the person doesn't even realise, they could resubscribe when the request comes around and the problem would continue. n0dalus. From aph at redhat.com Wed Feb 8 15:41:44 2006 From: aph at redhat.com (Andrew Haley) Date: Wed, 8 Feb 2006 15:41:44 +0000 Subject: [Fwd: Re: rawhide report: 20060207 changes] In-Reply-To: <6280325c0602080737y46b4911aga2637319bb935dfd@mail.gmail.com> References: <43E9B689.6050203@mharris.ca> <6280325c0602080339x63857c54qee401bf6d85eabed@mail.gmail.com> <43E9DD9C.1050803@mharris.ca> <200602080748.56664.sgrubb@redhat.com> <1139403512.4112.17.camel@tjikkun.dyndns.org> <1139407165.19396.12.camel@spikehome.5797net.local> <6280325c0602080737y46b4911aga2637319bb935dfd@mail.gmail.com> Message-ID: <17386.4408.883952.179083@zapata.pink> n0dalus writes: > > I think the best way is to just send an email to everyone. I have been > on the list for several months now and I have never gotten any > automated email like the one described earlier. This could be because > I'm not in the public subscriber list. Or perhaps the email wasn't To: > fedora-devel (because the responsible person may have a filter to only > forward some emails) or maybe it was sent in a way that wouldn't have > usually gotten a challenge from the UOL server. > > Someone asked why not everyone gets the emails. I am guessing it's > because some domains (like gmail, hotmail, etc) are whitelisted on > their server. > > I think a mass unique email is the best way. But if it's being done deliberately, even if we figure out the real address they can just re-subscribe with another alias. Andrew. From andy at warmcat.com Wed Feb 8 15:47:52 2006 From: andy at warmcat.com (Andy Green) Date: Wed, 08 Feb 2006 15:47:52 +0000 Subject: OLPC 'upstream' In-Reply-To: <1139408681.2584.9.camel@dhcp83-115.boston.redhat.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> <1139384082.15809.2.camel@rousalka.dyndns.org> <1139384578.3579.39.camel@ender> <1139408681.2584.9.camel@dhcp83-115.boston.redhat.com> Message-ID: <43EA12A8.6060306@warmcat.com> > Any real code changes are going to be done upstream if possible; the Just a FYI for people reading, I a Wiki "upstream" with more information about the project. http://pedia.media.mit.edu/wiki/OLPC_software_task_list http://pedia.media.mit.edu/wiki/Development_issues "We plan to use the JFFS2 journalling flash file system on the flash..." "At this point, OLPC looks most favorably on the GTK+/Pango/ATK toolkit" Sounds good! Be aware tho that large JFFS2 filesystems are really slow to mount. http://pedia.media.mit.edu/wiki/One_Laptop_per_Child "We expect the release of a beta version of the emulator in early February." And here is a hardware spec I didn't see before http://pedia.media.mit.edu/wiki/Hardware_specification * Processor: AMD Geode GX500 at 1.0W with AMD CS5536 companion chip (note that the "500" chip really operates at a 366MHz clock). * Memory: 128MB DRAM, possibly DDR Mobile * Nonvolatile storage: 512MB (possibly 1GB) NAND flash memory * BIOS/loader: hardware details TBD; either conventional, or maybe LinuxBIOS, if available in time. * Audio: AC97 codec (chip TBD; we are down to probably two or three alternatives), built-in stereo speakers and mono microphone, jacks for external stereo speakers and microphones * External ports: four USB2.0, one supporting On-The-Go functionality * Display: dual-mode, based on a 7.2" diagonal 800x600 monochrome TFT panel o Monochrome (high-res, low-power "E-Book") mode: 800x600, reflective (ambient light) o Color mode: 462x346, quincunx-sampled, LED-backlit * Input devices: keyboard, trackpad (supporting pointing, scrolling, and possibly graphical input), additional buttons adjacent to screen for use in E-Book/tablet mode * Wireless: Atheros AR5004G or AR5004GS chip, 802.11b/g. The requirements of mesh networking in combination with the abilities of the madwifi device driver have driven this selection; it is the best and most flexible wireless device driver today. There are not other viable alternatives at this time. * Power: 100-240VAC, 12VDC, also integrated crank charger based on a permanent-magnet generator and 100:1 gear train. Battery details TBD. Many of the TBD's should be set by late January, 2006, and we'll try to keep this page up to date. Actually quite encouraging, we'll see if "busybox" and "newlib" or "uclibc" form part of Rehdat's concept. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From n0dalus+redhat at gmail.com Wed Feb 8 15:48:51 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Thu, 9 Feb 2006 02:18:51 +1030 Subject: [Fwd: Re: rawhide report: 20060207 changes] In-Reply-To: <17386.4408.883952.179083@zapata.pink> References: <43E9B689.6050203@mharris.ca> <6280325c0602080339x63857c54qee401bf6d85eabed@mail.gmail.com> <43E9DD9C.1050803@mharris.ca> <200602080748.56664.sgrubb@redhat.com> <1139403512.4112.17.camel@tjikkun.dyndns.org> <1139407165.19396.12.camel@spikehome.5797net.local> <6280325c0602080737y46b4911aga2637319bb935dfd@mail.gmail.com> <17386.4408.883952.179083@zapata.pink> Message-ID: <6280325c0602080748i2536540ay4687003c26aa192d@mail.gmail.com> On 2/9/06, Andrew Haley wrote: > > But if it's being done deliberately, even if we figure out the real > address they can just re-subscribe with another alias. > If someone wanted to annoy everybody deliberately, there are much much better ways of doing it. They could forwards the list emails around to 20 accounts on email domains which send challenge requests. If they really wanted to they could automatically submit our email addresses to 1000 spam sites. The possibilities are endless. For this reason, I don't think it is deliberate. Even if it is, by sending a unique email to everyone we can find out soon enough. n0dalus. From jreiser at BitWagon.com Wed Feb 8 15:51:16 2006 From: jreiser at BitWagon.com (John Reiser) Date: Wed, 08 Feb 2006 07:51:16 -0800 Subject: nothing from buildsys? In-Reply-To: <43E9C43A.7050404@mharris.ca> References: <43E1E0BE.2080908@adslpipe.co.uk> <5256d0b0602020239s3aa68266p37346bfc4d493c12@mail.gmail.com> <43E32AAE.2030703@mharris.ca> <5256d0b0602030211k2631d39cgbbc767d5fb29fbcd@mail.gmail.com> <43E33244.7080605@mharris.ca> <20060207191930.GB5319@ti64.telemetry-investments.com> <43E9C43A.7050404@mharris.ca> Message-ID: <43EA1374.20700@BitWagon.com> > I just wondered what reasons people would download the SRPMS DVD ISO > image and burn it to a disk. SRPMS are useful, no question, but how > useful is a set of outdated SRPMS in a week or two? ;o) There is a non-ignorable set of installations that never yum or up2date. They always run the original official release and nothing else. They have very good external firewalls; some are even disconnected from all external networks. The users are either all experts, or all newbies. The budget for maintenance is zero. The disaster recovery plan for system software (as opposed to application data) is: re-install the last official release from the gold[en] CDs. This is guaranteed to be a perfect recovery, with no possibility of any changes. If you are a consultant to such a system, then the SRPMs DVD never becomes outdated. [Some of these systems do run RHEL named update rollups, such as Taroon Update 5. But it is installed fresh from the full CD .iso images, not as an upgrade to any earlier release.] -- From pjones at redhat.com Wed Feb 8 16:02:20 2006 From: pjones at redhat.com (Peter Jones) Date: Wed, 08 Feb 2006 11:02:20 -0500 Subject: dmraid comments and a warning In-Reply-To: <1139353995.3321.24.camel@mentorng.gurulabs.com> References: <1139256516.4440.66.camel@mentorng.gurulabs.com> <1139277727.1654.28.camel@localhost.localdomain> <1139296637.3599.24.camel@mentorng.gurulabs.com> <1139351640.15968.68.camel@localhost.localdomain> <1139353995.3321.24.camel@mentorng.gurulabs.com> Message-ID: <1139414540.15968.92.camel@localhost.localdomain> On Tue, 2006-02-07 at 16:13 -0700, Dax Kelson wrote: > On Tue, 2006-02-07 at 17:34 -0500, Peter Jones wrote: > > Are you sure about this? Your blkid.tab looks very much like you used > > the default layout on Jan 13... > > My para was regarding "event one" which got blown away and reinstalled > over. The blkid.tab I posted was from the next install I did which used > the auto-layout feature of disk druid. Oh, ok. I was just a bit confused on the timeframe between "one" and "two" then. > Physically the disks and their cables haven't been touched. > > I remember a big yum update that segfaulted half way through. Maybe > related? Could be, but it's pretty tenuous. For some reason you got a *complete* initrd that was merely wrong about your block devices. > I can look and see tonight when I get home. My guess right now is > whatever was in rawhide at that time. > > > So that means when you installed that, you were either already booted > > without using raid, or mkinitrd (or one of the many tools it uses) was > > broken. > > Yes. I'm sure I didn't closely observe every bootup sequence or was even > in the room while the boot occurred so it would be easy for me to have > missed something. [...] > I can attempt this if you still want. I don't think we're going to learn much more here. Thanks for the effort, though. -- Peter From katzj at redhat.com Wed Feb 8 16:06:41 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 08 Feb 2006 11:06:41 -0500 Subject: Testing Xen. Some quick questions. In-Reply-To: <1139376613.17114.37.camel@dragon.sys.intra> References: <1139368548.2603.35.camel@dragon.sys.intra> <1139371661.2907.66.camel@bree.local.net> <1139376613.17114.37.camel@dragon.sys.intra> Message-ID: <1139414801.22826.18.camel@bree.local.net> On Wed, 2006-02-08 at 14:30 +0900, Naoki wrote: > > > Is there a simple way to fake a netboot so I can use my existing > > > kickstart scripts and build OS instances the same way I would with > > > normal physical hardware? > > > > Realistically, the xenguest-install stuff is pretty much faking netboot. > > Run it with --help to see the way to pass the various things to it as > > command line arguments and you can use -x for passing things like ks= > > As we say in my country, "Sweet mate!". I've tested with current > rawhide and it's looking good except for the stage2 problem which I > think has already been covered today. > > Quick note about -l LOCATION, --location=LOCATION : > > "http://host:/path" may be confusing because it will not work with the > middle ":" unless a port is specified. Perhaps "http://host:port/path" > is better? Or just even http://host/path. I must have been sleep walking when I wrote that. Fixed it up for the next time I build the package Jeremy From katzj at redhat.com Wed Feb 8 16:06:53 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 08 Feb 2006 11:06:53 -0500 Subject: Testing Xen. Some quick questions. In-Reply-To: <04238730-1E23-4018-96E6-C3F31DD0A8D8@mac.com> References: <1139368548.2603.35.camel@dragon.sys.intra> <1139371661.2907.66.camel@bree.local.net> <1139376613.17114.37.camel@dragon.sys.intra> <04238730-1E23-4018-96E6-C3F31DD0A8D8@mac.com> Message-ID: <1139414813.22826.19.camel@bree.local.net> On Tue, 2006-02-07 at 22:15 -0800, Adam Huda wrote: > One suggestion for xenguest-install.py. You might want to set the > initial value of ram to 256. It is a little confusing when it prints > out "ERROR: Installs currently require 256 megs of RAM." in > interactive mode (running without any command line args) before your > prompted with "How much RAM should be allocated (in megabytes)? ". This should actually be handled better as of today's xen package Jeremy From dcbw at redhat.com Wed Feb 8 16:02:50 2006 From: dcbw at redhat.com (Dan Williams) Date: Wed, 08 Feb 2006 11:02:50 -0500 Subject: OLPC 'upstream' In-Reply-To: <43EA12A8.6060306@warmcat.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> <1139384082.15809.2.camel@rousalka.dyndns.org> <1139384578.3579.39.camel@ender> <1139408681.2584.9.camel@dhcp83-115.boston.redhat.com> <43EA12A8.6060306@warmcat.com> Message-ID: <1139414570.17900.8.camel@dhcp83-115.boston.redhat.com> On Wed, 2006-02-08 at 15:47 +0000, Andy Green wrote: > > Any real code changes are going to be done upstream if possible; the Well, by "upstream" I mean upstream in the projects for which the changes would be made. Like the Linux kernel, Gnome, glibc, etc. > "We plan to use the JFFS2 journalling flash file system on the flash..." > "At this point, OLPC looks most favorably on the GTK+/Pango/ATK toolkit" > > Sounds good! Be aware tho that large JFFS2 filesystems are really slow > to mount. Yep, and Dave Woodhouse knows the limitations quite well. Which is why he's beating JFFS2 into submission for OLPC as we speak. > Actually quite encouraging, we'll see if "busybox" and "newlib" or > "uclibc" form part of Rehdat's concept. Well, remember that while this machine has some low-end specs that match more of a "smart" cellphone rather than a real laptop, it still is more of a laptop. If you're running interesting apps on it, I'm not sure that things like uclibc would really work. Most of the highly slimmed down environments are targeted at PDAs that are quite a bit lower-speced than this laptop. With glibc, most of the size is actually taken up by all the locale information, which can certainly be stripped out for OLPC. The plan here is to use as much of Fedora Core as possible (including glibc) and only if there are severe space issues rethink that strategy. There really aren't many space issues however. The moderately slimmed JFFS2 image is under 250MB now, and there's still lots to be culled. I think the target is around 150MB - 200MB for the base OS and desktop library stack. That's quite reachable. Dan From katzj at redhat.com Wed Feb 8 16:08:20 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 08 Feb 2006 11:08:20 -0500 Subject: Testing Xen. Some quick questions. In-Reply-To: <1139406119.25572.32.camel@gilboa-work-dev> References: <1139368548.2603.35.camel@dragon.sys.intra> <1139406119.25572.32.camel@gilboa-work-dev> Message-ID: <1139414901.22826.22.camel@bree.local.net> On Wed, 2006-02-08 at 15:41 +0200, Gilboa Davara wrote: > (I know this has been asked times and times before.) > but... What's the current status of Xen/x86_64? It's being heavily worked on. Trust me, we want it as much as you do. > Second, considering the fact that rawhide/x86_64 still doesn't have > kernel-xen and the pending release of test3, what are the chances of > Xen/x86_64 making it's way into FC5? We're hopefully optimistic that we'll get something working before the test3 freeze so that it can be included in test3 and then the final FC5 > Any chance it'll make it into test3? (I assume that past test3, only bug > fixes will be introduced until FC5-release) See above. And yeah, if it doesn't make test3, chances for release are slim Jeremy From pjones at redhat.com Wed Feb 8 16:07:39 2006 From: pjones at redhat.com (Peter Jones) Date: Wed, 08 Feb 2006 11:07:39 -0500 Subject: dmraid comments and a warning In-Reply-To: <200602071622.42894.lamont@gurulabs.com> References: <1139256516.4440.66.camel@mentorng.gurulabs.com> <1139296637.3599.24.camel@mentorng.gurulabs.com> <1139351640.15968.68.camel@localhost.localdomain> <200602071622.42894.lamont@gurulabs.com> Message-ID: <1139414860.15968.98.camel@localhost.localdomain> On Tue, 2006-02-07 at 16:22 -0700, Lamont R. Peterson wrote: > On Tuesday 07 February 2006 03:34pm, Peter Jones wrote: > > On Tue, 2006-02-07 at 00:17 -0700, Dax Kelson wrote: > [snip] > > > And now it uses root=/dev/mapper/$DEV ? > > > > No, it still uses root=LABEL=/ (assuming no lvm), but the label > > searching mechanism early in the boot process is now the same as that > > used by mount, umount, swapon, etc., and it currently gives > > device-mapper devices a higher "priority", which should guarantee that, > > assuming it's possible to build the raid, all of those tools will use > > the dm device instead of the normal disks. > > Perhaps it would be better to have this defaulted on install to *not* use > LABEL= mounting syntax. It'd be better to not have the physical disk partition devices even exist when we're trying to bring up a system with a dmraid. I've got a patch to allow that, and I'm looking on getting it into the kernel (ours and upstream's) now. The patch adds a block device ioctl BLKRMPARTS, which simply turns all of the subdevices on a block device off. You can turn them back on with BLKRRPART, which is exposed to sysadmins via "/sbin/blockdev --rereadpt". I'll look at adding --rmparts to that utility as well. > In that case, the broken device would have prevented > mounting and, therefore, booting and the problem of dropping half the mirror > leading to this corruption would not happen without FRAID users knowing about > it. Yet another case where mounting using LABEL= syntax causes more problems > than it solves. It's not caused by mounting by label. It's caused by having a device that you can mount, but where mounting can *only* cause system corruption. (Don't get me wrong, I think mounting by label is a bit flawed, but "just don't do it" isn't quite right either.) -- Peter From pbrobinson at gmail.com Wed Feb 8 16:13:39 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 8 Feb 2006 16:13:39 +0000 Subject: OLPC 'upstream' In-Reply-To: <1139414570.17900.8.camel@dhcp83-115.boston.redhat.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> <1139384082.15809.2.camel@rousalka.dyndns.org> <1139384578.3579.39.camel@ender> <1139408681.2584.9.camel@dhcp83-115.boston.redhat.com> <43EA12A8.6060306@warmcat.com> <1139414570.17900.8.camel@dhcp83-115.boston.redhat.com> Message-ID: <5256d0b0602080813y50f7888fx4070bc2cfb830f5f@mail.gmail.com> > With glibc, most of the size is actually taken up by all the locale > information, which can certainly be stripped out for OLPC. The plan > here is to use as much of Fedora Core as possible (including glibc) and > only if there are severe space issues rethink that strategy. There > really aren't many space issues however. The moderately slimmed JFFS2 > image is under 250MB now, and there's still lots to be culled. I think > the target is around 150MB - 200MB for the base OS and desktop library > stack. That's quite reachable. Its almost similar to the maemo project in style where they've put a low end desktop style spec into a handheld. It has all the usuals like glibc, gtk (and co) gstreamer, X, window manager etc and fits in 128M I think so I wouldn't have thought it would be a major issue. Peter From dcbw at redhat.com Wed Feb 8 16:23:34 2006 From: dcbw at redhat.com (Dan Williams) Date: Wed, 08 Feb 2006 11:23:34 -0500 Subject: OLPC 'upstream' In-Reply-To: <5256d0b0602080813y50f7888fx4070bc2cfb830f5f@mail.gmail.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> <1139384082.15809.2.camel@rousalka.dyndns.org> <1139384578.3579.39.camel@ender> <1139408681.2584.9.camel@dhcp83-115.boston.redhat.com> <43EA12A8.6060306@warmcat.com> <1139414570.17900.8.camel@dhcp83-115.boston.redhat.com> <5256d0b0602080813y50f7888fx4070bc2cfb830f5f@mail.gmail.com> Message-ID: <1139415814.17900.30.camel@dhcp83-115.boston.redhat.com> On Wed, 2006-02-08 at 16:13 +0000, Peter Robinson wrote: > > With glibc, most of the size is actually taken up by all the locale > > information, which can certainly be stripped out for OLPC. The plan > > here is to use as much of Fedora Core as possible (including glibc) and > > only if there are severe space issues rethink that strategy. There > > really aren't many space issues however. The moderately slimmed JFFS2 > > image is under 250MB now, and there's still lots to be culled. I think > > the target is around 150MB - 200MB for the base OS and desktop library > > stack. That's quite reachable. > > Its almost similar to the maemo project in style where they've put a > low end desktop style spec into a handheld. It has all the usuals like > glibc, gtk (and co) gstreamer, X, window manager etc and fits in 128M > I think so I wouldn't have thought it would be a major issue. Exactly. They have quite a few Gnome-slimming patches of interest, like killing Bonobo until it's dead dead dead. Many of those are already upstream, or are going upstream to Gnome, AIUI. There's activity in this area that has nothing to do with OLPC specifically, but from which OLPC and others could benefit. So for the OLPC project, that means working with upstream projects and others like Maemo to ensure that the software is suitable for lower-end systems across the board. Dan From mharris at mharris.ca Wed Feb 8 16:27:13 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Wed, 08 Feb 2006 11:27:13 -0500 Subject: [Fwd: Re: rawhide report: 20060207 changes] In-Reply-To: <6280325c0602080748i2536540ay4687003c26aa192d@mail.gmail.com> References: <43E9B689.6050203@mharris.ca> <6280325c0602080339x63857c54qee401bf6d85eabed@mail.gmail.com> <43E9DD9C.1050803@mharris.ca> <200602080748.56664.sgrubb@redhat.com> <1139403512.4112.17.camel@tjikkun.dyndns.org> <1139407165.19396.12.camel@spikehome.5797net.local> <6280325c0602080737y46b4911aga2637319bb935dfd@mail.gmail.com> <17386.4408.883952.179083@zapata.pink> <6280325c0602080748i2536540ay4687003c26aa192d@mail.gmail.com> Message-ID: <43EA1BE1.8090101@mharris.ca> n0dalus wrote: > On 2/9/06, Andrew Haley wrote: > >>But if it's being done deliberately, even if we figure out the real >>address they can just re-subscribe with another alias. >> > > > If someone wanted to annoy everybody deliberately, there are much much > better ways of doing it. Or they could start an email thread about being upset over someone having an anonymous autoresponder on a mailing list. ;o) /me runs -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From pjones at redhat.com Wed Feb 8 16:37:27 2006 From: pjones at redhat.com (Peter Jones) Date: Wed, 08 Feb 2006 11:37:27 -0500 Subject: dmraid comments and a warning In-Reply-To: <1139414860.15968.98.camel@localhost.localdomain> References: <1139256516.4440.66.camel@mentorng.gurulabs.com> <1139296637.3599.24.camel@mentorng.gurulabs.com> <1139351640.15968.68.camel@localhost.localdomain> <200602071622.42894.lamont@gurulabs.com> <1139414860.15968.98.camel@localhost.localdomain> Message-ID: <1139416647.15968.101.camel@localhost.localdomain> On Wed, 2006-02-08 at 11:07 -0500, Peter Jones wrote: > It'd be better to not have the physical disk partition devices even > exist when we're trying to bring up a system with a dmraid. I've got a > patch to allow that, and I'm looking on getting it into the kernel (ours > and upstream's) now. > > The patch adds a block device ioctl BLKRMPARTS, which simply turns all > of the subdevices on a block device off. You can turn them back on with > BLKRRPART, which is exposed to sysadmins via "/sbin/blockdev > --rereadpt". I'll look at adding --rmparts to that utility as well. .. actually the patch may not be necessary, there's a way to remove individual partitions elsewhere in the kernel, and that may be usable. The functionality should probably still be added to /sbin/blockdev . -- Peter From pjones at redhat.com Wed Feb 8 16:41:21 2006 From: pjones at redhat.com (Peter Jones) Date: Wed, 08 Feb 2006 11:41:21 -0500 Subject: dmraid comments and a warning In-Reply-To: <200602071626.33773.lamont@gurulabs.com> References: <1139256516.4440.66.camel@mentorng.gurulabs.com> <1139277727.1654.28.camel@localhost.localdomain> <1139296637.3599.24.camel@mentorng.gurulabs.com> <200602071626.33773.lamont@gurulabs.com> Message-ID: <1139416882.15968.106.camel@localhost.localdomain> On Tue, 2006-02-07 at 16:26 -0700, Lamont R. Peterson wrote: > On Tuesday 07 February 2006 12:17am, Dax Kelson wrote: > > 2.6.15-1.1884 = dm commands inside "init" > > 2.6.15-1.1889 - no dm commands inside "init" -- dated Feb 4th on my box > > I would think that is the fault of mkinitrd. It may be, but there's no shortage of other things that could have gone wrong. There's not enough information to be sure. > At any rate, we need to test if > mkinitrd will bring the right FRAID driver(s) into initrds that it creates. There aren't any drivers. It's all device-mapper. > Perhaps the mirror broke the first time you booted with the new kernel. No, if that were the case blkid.tab would have older timestamps than Feb 5 for the newer entries. It'd have them from the reboot after the install finished. We can be certain that the first reboot brought the raid up just fine. -- Peter From toshio at tiki-lounge.com Wed Feb 8 16:56:14 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 08 Feb 2006 08:56:14 -0800 Subject: rawhide report: 20060207 changes In-Reply-To: <1139372859.1084.112.camel@mccallum.corsepiu.local> References: <200602070834.k178YGVA017981@porkchop.devel.redhat.com> <1139309034.1084.53.camel@mccallum.corsepiu.local> <43E890F1.9060903@mharris.ca> <1139334073.4897.16.camel@localhost> <1139372859.1084.112.camel@mccallum.corsepiu.local> Message-ID: <1139417774.3380.12.camel@localhost> On Wed, 2006-02-08 at 05:27 +0100, Ralf Corsepius wrote: > On Tue, 2006-02-07 at 09:41 -0800, Toshio Kuratomi wrote: > > On Tue, 2006-02-07 at 07:22 -0500, Mike A. Harris wrote: > > > If a package wishes to retain build time compatibility with > > > X11R6 et al. it could use fallbacks if the pkg-config files > > > aren't present, however from here on out, using pkgconfig > > > is the very highly recommended way to detect the X libraries > > > and other bits and pieces. > > > > > Where should this be implemented? > Inside of a package's configure script. > > What Mike says, basically boils down to treat "X libs" as you would > handle other libraries. > > The most simple but also most flexible approach would be to use > AC_CHECK_HEADERS/AC_CHECK_LIBS on each of the files being used by a > package. This essentially means shifting selection of directories/paths > to the user > (configure CPPFLAGS=-I/usr/X11R6/include LDFLAGS=-L/usr/X11R6/lib) > > However, in practice, this is hardly applicable on X11 packages (It is > the reason why AC_PATH_X* exist) :( > > > Should AC_PATH_X/XTRA be changed to > > attempt to use pkgconfig as a first choice and then use AC_PATH_X if it > > isn't found? (I don't know how autoconf deals with dependencies on > > optional m4 macros but for now I'm supposing this is possible) > Providing aclocal macros/wrappers around pkg-config is task of the > package providing the *.pc-file, i.e. each of those X11-libraries would > have to provide them (c.f. how gtk/gnome handles this). > > > Or does every package using AC_PATH_X need to create the logic for using > > pkg-config with optional fallbacks to X11R6 behavior and then try to > > push those changes upstream (using autoconf/autoconf-patches until the > > changes are accepted and released.) > It depends. As I see it, you have 4 choices: > > 1. Use the old fsf-autoconf behavior: I.e. use AC_PATH_X* with the check > for Xt, and presume all X11 files to be installed to the same > directories. Rpm-wise, you'd have to "BR: libXt-devel" in all such > packages, and the behavior should be the same as it has been so far. > > This would be the "short term and least invasive" approach. [snip] > > 3. Rely on the X11R7-packages providing appropriate *.pc files, and > abandon X11R6. Then using PKG_CHECK_MODULES(...) in configure scripts > should be sufficient. This is the most simple approach, but means > breaking backward compatibility. > > > 4. Pragmatically combine 1-3. I'd expect combining 3 + 1 is what would > be the "common approach". Right. I agree on that. What I'm wondering is whether I should propose a patch to upstream autoconf that changes the behaviour of AC_PATH_X to try pkg-config, then xmkmf, then _AC_PATH_DIRECT to determine it's magic, sloppy paths, or if I should instead spend time designing a configure.ac snippet that attempts pkg-config and then falls back on the current AC_PATH_X (so Fedora packagers can make the changes to configure.ac and propose backward-compatible patches to all upstream projects using AC_PATH_X.) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From andy at warmcat.com Wed Feb 8 16:58:51 2006 From: andy at warmcat.com (Andy Green) Date: Wed, 08 Feb 2006 16:58:51 +0000 Subject: OLPC 'upstream' In-Reply-To: <1139414570.17900.8.camel@dhcp83-115.boston.redhat.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> <1139384082.15809.2.camel@rousalka.dyndns.org> <1139384578.3579.39.camel@ender> <1139408681.2584.9.camel@dhcp83-115.boston.redhat.com> <43EA12A8.6060306@warmcat.com> <1139414570.17900.8.camel@dhcp83-115.boston.redhat.com> Message-ID: <43EA234B.2060601@warmcat.com> Dan Williams wrote: >>Actually quite encouraging, we'll see if "busybox" and "newlib" or >>"uclibc" form part of Rehdat's concept. > > Well, remember that while this machine has some low-end specs that match > more of a "smart" cellphone rather than a real laptop, it still is more > of a laptop. If you're running interesting apps on it, I'm not sure > that things like uclibc would really work. Most of the highly slimmed > down environments are targeted at PDAs that are quite a bit lower-speced > than this laptop. uclibc is pretty friendly to the apps I have compiled it with, including fairly large things like Asterisk. This isn't very scientific, but Fedora x86_64: 1485672 Aug 15 15:34 /lib/libc-2.3.5.so Our ARM distro: 256988 Jan 18 11:15 /lib/libuClibc-0.9.28.so http://uclibc.org/FAQ.html#why and the next FAQ entry have some information about the goals and compatibility. > With glibc, most of the size is actually taken up by all the locale > information, which can certainly be stripped out for OLPC. The plan Yep. > here is to use as much of Fedora Core as possible (including glibc) and > only if there are severe space issues rethink that strategy. There > really aren't many space issues however. The moderately slimmed JFFS2 > image is under 250MB now, and there's still lots to be culled. I think > the target is around 150MB - 200MB for the base OS and desktop library > stack. That's quite reachable. Are these "JFFS2 image" figures, after the JFFS2 compression? Just some example numbers, busybox on my Arm9 here is 606KB and allows you to throw away bash (it has ash), vi, coreutils, rpm (a weaker implementation, but still), cpio, tar, procps, etc, etc, even networking stuff like dhcpd and dhcpc are all in there. If you accept some small restrictions and losses of non-core functionality you can perform a massive reduction in distro size and packagecount with busybox with or without an alternative libc. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From alan at redhat.com Wed Feb 8 17:04:40 2006 From: alan at redhat.com (Alan Cox) Date: Wed, 8 Feb 2006 12:04:40 -0500 Subject: OLPC 'upstream' In-Reply-To: <43EA12A8.6060306@warmcat.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> <1139384082.15809.2.camel@rousalka.dyndns.org> <1139384578.3579.39.camel@ender> <1139408681.2584.9.camel@dhcp83-115.boston.redhat.com> <43EA12A8.6060306@warmcat.com> Message-ID: <20060208170440.GA1460@devserv.devel.redhat.com> On Wed, Feb 08, 2006 at 03:47:52PM +0000, Andy Green wrote: > requirements of mesh networking in combination with the abilities of the > madwifi device driver have driven this selection; it is the best and > most flexible wireless device driver today. There are not other viable > alternatives at this time. Madwifi is not free software. Alan From dax at gurulabs.com Wed Feb 8 17:11:25 2006 From: dax at gurulabs.com (Dax Kelson) Date: Wed, 08 Feb 2006 10:11:25 -0700 Subject: dmraid comments and a warning In-Reply-To: <1139414540.15968.92.camel@localhost.localdomain> References: <1139256516.4440.66.camel@mentorng.gurulabs.com> <1139277727.1654.28.camel@localhost.localdomain> <1139296637.3599.24.camel@mentorng.gurulabs.com> <1139351640.15968.68.camel@localhost.localdomain> <1139353995.3321.24.camel@mentorng.gurulabs.com> <1139414540.15968.92.camel@localhost.localdomain> Message-ID: <1139418685.3313.5.camel@mentorng.gurulabs.com> On Wed, 2006-02-08 at 11:02 -0500, Peter Jones wrote: > I don't think we're going to learn much more here. Thanks for the > effort, though. Just doing my part. :) I'll wait till the rawhide churn settles down and then re-install. Dax Kelson Guru Labs From pbrobinson at gmail.com Wed Feb 8 17:16:17 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 8 Feb 2006 17:16:17 +0000 Subject: OLPC 'upstream' In-Reply-To: <43EA234B.2060601@warmcat.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> <1139384082.15809.2.camel@rousalka.dyndns.org> <1139384578.3579.39.camel@ender> <1139408681.2584.9.camel@dhcp83-115.boston.redhat.com> <43EA12A8.6060306@warmcat.com> <1139414570.17900.8.camel@dhcp83-115.boston.redhat.com> <43EA234B.2060601@warmcat.com> Message-ID: <5256d0b0602080916o13d09dc5r7d59101c8c6d0762@mail.gmail.com> > Are these "JFFS2 image" figures, after the JFFS2 compression? Just some > example numbers, busybox on my Arm9 here is 606KB and allows you to > throw away bash (it has ash), vi, coreutils, rpm (a weaker > implementation, but still), cpio, tar, procps, etc, etc, even networking > stuff like dhcpd and dhcpc are all in there. If you accept some small > restrictions and losses of non-core functionality you can perform a > massive reduction in distro size and packagecount with busybox with or > without an alternative libc. But while not throwing away core functionality you add extra unneeded things like extra development and testing time (and a reduced audience for testing) by using things like uclibc in a fedora based distro and hence increasing the developments costs and time to market with very little gain in size. Things like maemo already prove that you can shoehorn all core functionality that you have in a modern desktop environment (I have a browser, abiword, gaim, gnumeric, evince and other stuff installed on the standard 128M on the Nokia 770 along with the standard browser/autio/video etc that comes default) into less than 256 without having to resort to using cut down libraries like uclib which may produce other issues. The advantage of using the core fedora libraries is that you have economies of scale when it comes to testing and bug hunting. Peter From andy at warmcat.com Wed Feb 8 17:24:04 2006 From: andy at warmcat.com (Andy Green) Date: Wed, 08 Feb 2006 17:24:04 +0000 Subject: OLPC 'upstream' In-Reply-To: <5256d0b0602080916o13d09dc5r7d59101c8c6d0762@mail.gmail.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> <1139384082.15809.2.camel@rousalka.dyndns.org> <1139384578.3579.39.camel@ender> <1139408681.2584.9.camel@dhcp83-115.boston.redhat.com> <43EA12A8.6060306@warmcat.com> <1139414570.17900.8.camel@dhcp83-115.boston.redhat.com> <43EA234B.2060601@warmcat.com> <5256d0b0602080916o13d09dc5r7d59101c8c6d0762@mail.gmail.com> Message-ID: <43EA2934.6020702@warmcat.com> Peter Robinson wrote: >>Are these "JFFS2 image" figures, after the JFFS2 compression? Just some >>example numbers, busybox on my Arm9 here is 606KB and allows you to >>throw away bash (it has ash), vi, coreutils, rpm (a weaker >>implementation, but still), cpio, tar, procps, etc, etc, even networking >>stuff like dhcpd and dhcpc are all in there. If you accept some small >>restrictions and losses of non-core functionality you can perform a >>massive reduction in distro size and packagecount with busybox with or >>without an alternative libc. > uclib which may produce other issues. The advantage of using the core > fedora libraries is that you have economies of scale when it comes to > testing and bug hunting. Accepted that in reality that is also a consideration. But really you are not playing the PC game any more on a box with 512MB flash. I also have a 770 and for all its good points it is crashy with the current firmware image, locks up on low memory situations and so on. Anyway the libc question is different to the busybox question. Does this laptop really need a full bash? A full *.rpm that will be in the minimal packageset? If not, busybox can soak up a huge area in the middle of the distro. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From andy at warmcat.com Wed Feb 8 17:24:56 2006 From: andy at warmcat.com (Andy Green) Date: Wed, 08 Feb 2006 17:24:56 +0000 Subject: OLPC 'upstream' In-Reply-To: <20060208170440.GA1460@devserv.devel.redhat.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> <1139384082.15809.2.camel@rousalka.dyndns.org> <1139384578.3579.39.camel@ender> <1139408681.2584.9.camel@dhcp83-115.boston.redhat.com> <43EA12A8.6060306@warmcat.com> <20060208170440.GA1460@devserv.devel.redhat.com> Message-ID: <43EA2968.3050907@warmcat.com> Alan Cox wrote: > On Wed, Feb 08, 2006 at 03:47:52PM +0000, Andy Green wrote: > >>requirements of mesh networking in combination with the abilities of the >>madwifi device driver have driven this selection; it is the best and >>most flexible wireless device driver today. There are not other viable >>alternatives at this time. > > > Madwifi is not free software. http://madwifi.org/wiki/ngFeatures License and HAL * The license for the driver has not changed. It is still dual BSD / GPL v2 licensed. * The HAL is still binary only and will still taint the kernel. http://madwifi.org/browser/trunk/hal http://madwifi.org/browser/trunk/hal/public Hm http://pedia.media.mit.edu/wiki/OLPC_on_open_source_software ? Must include source code and allow modification so that our developers, the governments that are our customers and the children who use the laptop can look under the hood change the software to fit an inconceivable and inconceivably diverse set of needs. Our software must also provide a self-hosting development platform. ? Must allow distribution of modified copies of software under the same license so that the freedoms that our developers depend upon for success remain available to the users and developers who define the next generation of the software. Our users and customers must be able to localize software into their language, fix the software to remove bugs, and repurpose the software to fit their needs. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From green at redhat.com Wed Feb 8 17:28:49 2006 From: green at redhat.com (Anthony Green) Date: Wed, 08 Feb 2006 09:28:49 -0800 Subject: Java on x86_64 In-Reply-To: <1139405483.8135.85.camel@xpc.home.erwinrol.com> References: <1139405483.8135.85.camel@xpc.home.erwinrol.com> Message-ID: <1139419730.3367.251.camel@localhost.localdomain> On Wed, 2006-02-08 at 14:31 +0100, Erwin Rol wrote: > Is there any hope the java GC bug > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179228 > > will be solved in the near future. I think only Ingo knows the status of that bug. > Since it prevents the use of pretty > much every java application, so those applications aren't being tested > anymore. And most java applications, like eclipse, are huge and > certainly could use every minute of testing. My only suggestion is to keep running the old 2.6.15-1.1826.2.10_FC5 kernel. AG From gilboad at gmail.com Wed Feb 8 17:38:15 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 08 Feb 2006 19:38:15 +0200 Subject: Testing Xen. Some quick questions. In-Reply-To: <1139414901.22826.22.camel@bree.local.net> References: <1139368548.2603.35.camel@dragon.sys.intra> <1139406119.25572.32.camel@gilboa-work-dev> <1139414901.22826.22.camel@bree.local.net> Message-ID: <1139420295.25572.41.camel@gilboa-work-dev> On Wed, 2006-02-08 at 11:08 -0500, Jeremy Katz wrote: > On Wed, 2006-02-08 at 15:41 +0200, Gilboa Davara wrote: > > (I know this has been asked times and times before.) > > > but... What's the current status of Xen/x86_64? > > It's being heavily worked on. Trust me, we want it as much as you do. > > > Second, considering the fact that rawhide/x86_64 still doesn't have > > kernel-xen and the pending release of test3, what are the chances of > > Xen/x86_64 making it's way into FC5? > > We're hopefully optimistic that we'll get something working before the > test3 freeze so that it can be included in test3 and then the final FC5 > > > Any chance it'll make it into test3? (I assume that past test3, only bug > > fixes will be introduced until FC5-release) > > See above. And yeah, if it doesn't make test3, chances for release are > slim > > Jeremy > OK. Thanks for the update. Gilboa From jkeating at j2solutions.net Wed Feb 8 17:49:59 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 08 Feb 2006 09:49:59 -0800 Subject: Ugly X11 pointers In-Reply-To: <43E9CB5C.4060306@zoeloelip.be> References: <43E9CB5C.4060306@zoeloelip.be> Message-ID: <1139420999.3579.57.camel@ender> On Wed, 2006-02-08 at 11:43 +0100, Bart Vanbrabant wrote: > > A few weeks back in rawhide only X11 cursors worked. This was fixed same > time later. I re?nstalled from rawhide a few days back and now I only > see the X11 cursors. If I select an other cursor theme in the Mouse > dialog under preferences I see that cursor theme for new programs but > after a new login the ugly X11 cursors are back. > Should this be filled as a bug report? > Do you have libXcursor-devel installed, and if not, can you install it then logout/login and see if you get the nice cursors back? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bart.vanbrabant at zoeloelip.be Wed Feb 8 18:19:16 2006 From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant) Date: Wed, 08 Feb 2006 19:19:16 +0100 Subject: Ugly X11 pointers In-Reply-To: <1139420999.3579.57.camel@ender> References: <43E9CB5C.4060306@zoeloelip.be> <1139420999.3579.57.camel@ender> Message-ID: <43EA3624.9030106@zoeloelip.be> Jesse Keating wrote: > On Wed, 2006-02-08 at 11:43 +0100, Bart Vanbrabant wrote: > >> A few weeks back in rawhide only X11 cursors worked. This was fixed same >> time later. I re?nstalled from rawhide a few days back and now I only >> see the X11 cursors. If I select an other cursor theme in the Mouse >> dialog under preferences I see that cursor theme for new programs but >> after a new login the ugly X11 cursors are back. >> Should this be filled as a bug report? >> >> > > Do you have libXcursor-devel installed, and if not, can you install it > then logout/login and see if you get the nice cursors back? > > That fixed the problem. This also explains why it used to be fixed. -- Bart Vanbrabant PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jkeating at j2solutions.net Wed Feb 8 18:44:34 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 08 Feb 2006 10:44:34 -0800 Subject: Ugly X11 pointers In-Reply-To: <43EA3624.9030106@zoeloelip.be> References: <43E9CB5C.4060306@zoeloelip.be> <1139420999.3579.57.camel@ender> <43EA3624.9030106@zoeloelip.be> Message-ID: <1139424274.3579.59.camel@ender> On Wed, 2006-02-08 at 19:19 +0100, Bart Vanbrabant wrote: > That fixed the problem. This also explains why it used to be fixed. Ok, there is already a bug on this, thanks for confirming. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pemboa at gmail.com Wed Feb 8 19:00:33 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 8 Feb 2006 13:00:33 -0600 Subject: Fedora in need of testers? In-Reply-To: <20051223074648.GA1842@tomservo.boston.redhat.com> References: <16de708d0512222319p3307eac0k476dc2b1b0a0a061@mail.gmail.com> <20051223074648.GA1842@tomservo.boston.redhat.com> Message-ID: <16de708d0602081100m8879378u91bea43fa892c79e@mail.gmail.com> On 12/23/05, Luke Macken wrote: > > On Fri, Dec 23, 2005 at 01:19:59AM -0600, Arthur Pemberton wrote: > | I got the feeling from looking aroung the mailing lists that fedora is > in > | need of testers. I am willing to use my FC4 on my Compaq Preasio 2210US > to > | do some testing. I have a desktop with FC4 installed but it is my > primary > | OS/machine, so I rather not play around on it. > | > | What would be required of a potential tester? > > Your help would be much appreciated. Every little bit counts. > > You can start by checking out our Testing Guide: > http://fedoraproject.org/wiki/Docs/Drafts/TestingGuide > > luke How can I help with a lowly 500 MHz machine I have acquired? It wasn't what I was expecting originally, but that's because my original plans fell through. -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at fubar.dk Wed Feb 8 19:37:23 2006 From: david at fubar.dk (David Zeuthen) Date: Wed, 08 Feb 2006 14:37:23 -0500 Subject: OLPC 'upstream' In-Reply-To: <43EA2934.6020702@warmcat.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> <1139384082.15809.2.camel@rousalka.dyndns.org> <1139384578.3579.39.camel@ender> <1139408681.2584.9.camel@dhcp83-115.boston.redhat.com> <43EA12A8.6060306@warmcat.com> <1139414570.17900.8.camel@dhcp83-115.boston.redhat.com> <43EA234B.2060601@warmcat.com> <5256d0b0602080916o13d09dc5r7d59101c8c6d0762@mail.gmail.com> <43EA2934.6020702@warmcat.com> Message-ID: <1139427443.3130.12.camel@daxter.boston.redhat.com> On Wed, 2006-02-08 at 17:24 +0000, Andy Green wrote: > Does this laptop really need a full bash? Does this laptop really need a shell? David From drepper at redhat.com Wed Feb 8 19:42:18 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Wed, 08 Feb 2006 11:42:18 -0800 Subject: caution with latest kernel + glibc In-Reply-To: <20060208131220.GA7056@ti64.telemetry-investments.com> References: <43E518BA.3010207@redhat.com> <20060208131220.GA7056@ti64.telemetry-investments.com> Message-ID: <43EA499A.7050303@redhat.com> Bill Rugolsky Jr. wrote: > 1909 x86_64 still locked up on my Tyan 2885 SMP, but 1914 has been up ten > hours and has shuffled more than 300GB on disk using cpio (local) and > rsync (remote). I have also still constant lockups. But they are not related to the bug fixed with the patch referenced in the bug. That part is fixed, I'm pretty sure. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From andy at warmcat.com Wed Feb 8 19:44:02 2006 From: andy at warmcat.com (Andy Green) Date: Wed, 08 Feb 2006 19:44:02 +0000 Subject: OLPC 'upstream' In-Reply-To: <1139427443.3130.12.camel@daxter.boston.redhat.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> <1139384082.15809.2.camel@rousalka.dyndns.org> <1139384578.3579.39.camel@ender> <1139408681.2584.9.camel@dhcp83-115.boston.redhat.com> <43EA12A8.6060306@warmcat.com> <1139414570.17900.8.camel@dhcp83-115.boston.redhat.com> <43EA234B.2060601@warmcat.com> <5256d0b0602080916o13d09dc5r7d59101c8c6d0762@mail.gmail.com> <43EA2934.6020702@warmcat.com> <1139427443.3130.12.camel@daxter.boston.redhat.com> Message-ID: <43EA4A02.7040505@warmcat.com> David Zeuthen wrote: > On Wed, 2006-02-08 at 17:24 +0000, Andy Green wrote: > >>Does this laptop really need a full bash? > > Does this laptop really need a shell? Is it having initscripts? -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From dcbw at redhat.com Wed Feb 8 19:48:49 2006 From: dcbw at redhat.com (Dan Williams) Date: Wed, 08 Feb 2006 14:48:49 -0500 Subject: OLPC 'upstream' In-Reply-To: <43EA4A02.7040505@warmcat.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> <1139384082.15809.2.camel@rousalka.dyndns.org> <1139384578.3579.39.camel@ender> <1139408681.2584.9.camel@dhcp83-115.boston.redhat.com> <43EA12A8.6060306@warmcat.com> <1139414570.17900.8.camel@dhcp83-115.boston.redhat.com> <43EA234B.2060601@warmcat.com> <5256d0b0602080916o13d09dc5r7d59101c8c6d0762@mail.gmail.com> <43EA2934.6020702@warmcat.com> <1139427443.3130.12.camel@daxter.boston.redhat.com> <43EA4A02.7040505@warmcat.com> Message-ID: <1139428129.28051.3.camel@dhcp83-115.boston.redhat.com> On Wed, 2006-02-08 at 19:44 +0000, Andy Green wrote: > David Zeuthen wrote: > > On Wed, 2006-02-08 at 17:24 +0000, Andy Green wrote: > > > >>Does this laptop really need a full bash? > > > > Does this laptop really need a shell? > > Is it having initscripts? Not necessarily ones that require a shell to execute. The target users have nearly no use for a shell (or if they need one, we haven't done our job). Fedora's initscripts are a stinking pile of crap right now anyway. There's some room to rethink the init process for these things, and maybe that means ditching the dependency on a shell _during the init process_. Dan From barryn at pobox.com Wed Feb 8 19:56:43 2006 From: barryn at pobox.com (Barry K. Nathan) Date: Wed, 8 Feb 2006 11:56:43 -0800 Subject: Fedora in need of testers? In-Reply-To: <16de708d0602081100m8879378u91bea43fa892c79e@mail.gmail.com> References: <16de708d0512222319p3307eac0k476dc2b1b0a0a061@mail.gmail.com> <20051223074648.GA1842@tomservo.boston.redhat.com> <16de708d0602081100m8879378u91bea43fa892c79e@mail.gmail.com> Message-ID: <986ed62e0602081156i79156d89u4251187d27c9541d@mail.gmail.com> On 2/8/06, Arthur Pemberton wrote: > How can I help with a lowly 500 MHz machine I have acquired? It wasn't what > I was expecting originally, but that's because my original plans fell > through. As long as it has enough RAM (check the release notes) and some free disk space, and as long as you have a little patience, it should be fine for testing. I'm coming back to Fedora Core testing after a long break (for various reasons)... with a 350MHz machine. ^_^ -- -Barry K. Nathan From andy at warmcat.com Wed Feb 8 20:07:58 2006 From: andy at warmcat.com (Andy Green) Date: Wed, 08 Feb 2006 20:07:58 +0000 Subject: OLPC 'upstream' In-Reply-To: <1139428129.28051.3.camel@dhcp83-115.boston.redhat.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> <1139384082.15809.2.camel@rousalka.dyndns.org> <1139384578.3579.39.camel@ender> <1139408681.2584.9.camel@dhcp83-115.boston.redhat.com> <43EA12A8.6060306@warmcat.com> <1139414570.17900.8.camel@dhcp83-115.boston.redhat.com> <43EA234B.2060601@warmcat.com> <5256d0b0602080916o13d09dc5r7d59101c8c6d0762@mail.gmail.com> <43EA2934.6020702@warmcat.com> <1139427443.3130.12.camel@daxter.boston.redhat.com> <43EA4A02.7040505@warmcat.com> <1139428129.28051.3.camel@dhcp83-115.boston.redhat.com> Message-ID: <43EA4F9E.60905@warmcat.com> Dan Williams wrote: >>>>Does this laptop really need a full bash? >>> >>>Does this laptop really need a shell? >> >>Is it having initscripts? > > Not necessarily ones that require a shell to execute. The target users > have nearly no use for a shell (or if they need one, we haven't done our Still, ssh-ing into a box is normally very useful, and you really want to come up into a shell. But I take your point. > job). Fedora's initscripts are a stinking pile of crap right now > anyway. There's some room to rethink the init process for these things, > and maybe that means ditching the dependency on a shell _during the init > process_. I saw a lot of work was done mapping what happens during boot and initscripts and where the time is going. There's stuff like initng (http://initng.thinktux.net/index.php/Main_Page ) so that sounds like a great idea for Fedora too. But ash in busybox really is negligible, sad to disallow the possibility of simple enduser scripts tying coreutils together with, eg, wget, for HTML screenscraping or whatever. Still good to hear this radical thoughtprocess is underway! -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From mailinglists at erwinrol.com Wed Feb 8 20:09:37 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 08 Feb 2006 21:09:37 +0100 Subject: FireMV 2400 PCI Quad Head Card Message-ID: <1139429377.8135.131.camel@xpc.home.erwinrol.com> Hey all, I got my quad head card working, but have some small problems. First it I get a weird Xinerama setup, it looks like two big screens divided over 4 monitors. When i maximize a window on monitor 1 it will take up the place of Monitor 1 and 2, when i maximize a window on monitor 3 it takes up monitor 3 and 4. It would be nice if Xinerama knew about the 4 monitors, the MergedXinerama option doesn't seem to do a thing, on or off the result is the same. But i could life with that problem. What is stranger is that a screen dump shows monitor 3/4 as black. It seems as if only the first part of the Xinerama desktop gets into the screenshot, is this also happening with dual head setups ? But that this works makes me very happy :-) cause hacking X could have been an endless project (for me at least :-) - Erwin PS: this card only works with the latest patch from Benjamin, as found in the xorg mailing list archives. -------------- next part -------------- A non-text attachment was scrubbed... Name: qh.png Type: image/png Size: 22315 bytes Desc: not available URL: From lamont at gurulabs.com Wed Feb 8 20:16:28 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Wed, 8 Feb 2006 13:16:28 -0700 Subject: caution with latest kernel + glibc In-Reply-To: <43EA499A.7050303@redhat.com> References: <43E518BA.3010207@redhat.com> <20060208131220.GA7056@ti64.telemetry-investments.com> <43EA499A.7050303@redhat.com> Message-ID: <200602081316.32971.lamont@gurulabs.com> On Wednesday 08 February 2006 12:42pm, Ulrich Drepper wrote: > Bill Rugolsky Jr. wrote: > > 1909 x86_64 still locked up on my Tyan 2885 SMP, but 1914 has been up ten > > hours and has shuffled more than 300GB on disk using cpio (local) and > > rsync (remote). > > I have also still constant lockups. But they are not related to the bug > fixed with the patch referenced in the bug. That part is fixed, I'm > pretty sure. On my Dual Opteron system at home (2x242 procs on a Tyan 2885 motherboard) and I have not been able to keep the system up since the first 2.6.13 kernels for FC4. The 2.6.12's all work fine. The (hard) lockups seem to occur after about the same quantity of file I/O regardless of how much time passes or where that I/O is going; could be local or NFS, HD or CD, etc. I can always lock it up at the exact same spot for each kernel those each one has a different spot, by booting, logging in and firing off an rpmbuild. I've been traveling these last couple of weeks, so I have not been home to try out the new 2.6.15 kernels. I'll do that Saturday and let you know. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From zaitcev at redhat.com Wed Feb 8 20:30:07 2006 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 8 Feb 2006 12:30:07 -0800 Subject: OLPC 'upstream' In-Reply-To: <1139427443.3130.12.camel@daxter.boston.redhat.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> <1139384082.15809.2.camel@rousalka.dyndns.org> <1139384578.3579.39.camel@ender> <1139408681.2584.9.camel@dhcp83-115.boston.redhat.com> <43EA12A8.6060306@warmcat.com> <1139414570.17900.8.camel@dhcp83-115.boston.redhat.com> <43EA234B.2060601@warmcat.com> <5256d0b0602080916o13d09dc5r7d59101c8c6d0762@mail.gmail.com> <43EA2934.6020702@warmcat.com> <1139427443.3130.12.camel@daxter.boston.redhat.com> Message-ID: <20060208123007.1f893b64.zaitcev@redhat.com> On Wed, 08 Feb 2006 14:37:23 -0500, David Zeuthen wrote: > On Wed, 2006-02-08 at 17:24 +0000, Andy Green wrote: > > Does this laptop really need a full bash? > > Does this laptop really need a shell? Yes, it does. There's a very large number of shell snippets embedded into applications. You may choose not to bundle gnome-terminal, that would be fine. But /bin/bash must be there and lame substitutions create problems which are not worth the saved space. -- Pete From zaitcev at redhat.com Wed Feb 8 20:32:06 2006 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 8 Feb 2006 12:32:06 -0800 Subject: OLPC 'upstream' In-Reply-To: <43EA12A8.6060306@warmcat.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> <1139384082.15809.2.camel@rousalka.dyndns.org> <1139384578.3579.39.camel@ender> <1139408681.2584.9.camel@dhcp83-115.boston.redhat.com> <43EA12A8.6060306@warmcat.com> Message-ID: <20060208123206.6cf36eee.zaitcev@redhat.com> On Wed, 08 Feb 2006 15:47:52 +0000, Andy Green wrote: > Actually quite encouraging, we'll see if "busybox" and "newlib" or > "uclibc" form part of Rehdat's concept. You must be raving mad to suggest uclibc. Was that supposed to be a sarcastic pun on the miniscule RAM spec? -- Pete From lamont at gurulabs.com Wed Feb 8 20:36:19 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Wed, 8 Feb 2006 13:36:19 -0700 Subject: Fedora in need of testers? In-Reply-To: <986ed62e0602081156i79156d89u4251187d27c9541d@mail.gmail.com> References: <16de708d0512222319p3307eac0k476dc2b1b0a0a061@mail.gmail.com> <16de708d0602081100m8879378u91bea43fa892c79e@mail.gmail.com> <986ed62e0602081156i79156d89u4251187d27c9541d@mail.gmail.com> Message-ID: <200602081336.23788.lamont@gurulabs.com> On Wednesday 08 February 2006 12:56pm, Barry K. Nathan wrote: > On 2/8/06, Arthur Pemberton wrote: > > How can I help with a lowly 500 MHz machine I have acquired? It wasn't > > what I was expecting originally, but that's because my original plans > > fell through. > > As long as it has enough RAM (check the release notes) and some free > disk space, and as long as you have a little patience, it should be > fine for testing. > > I'm coming back to Fedora Core testing after a long break (for various > reasons)... with a 350MHz machine. ^_^ I think having some slow machines in the mix is good. We don't want to be building a distribution that suddenly only runs "tolerably" on "the last 20% of the speed curve" hardware. Then again, those with "only" slow machines need to be cautious of becoming "numb" about performance. After a while, you get used to the speed of your machine (screaming fast, painfully slow or anywhere in between) and it can become very easy to overlook the changes in performance. I think the best defense against that is awareness + hard numbers (benchmark). "time" is your friend :) . It turns fuzzy time into something that we can all talk about. So, to those with "slow" boxes; happy testing. P.S. I don't speak for the Fedora Project :) . -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bdwheele at indiana.edu Wed Feb 8 20:54:37 2006 From: bdwheele at indiana.edu (Brian Wheeler) Date: Wed, 08 Feb 2006 15:54:37 -0500 Subject: Xen network failing Message-ID: <1139432077.3796.11.camel@wombat.dlib.indiana.edu> I've been trying to get xen working on fc5t2 + rawhide and I just can't get the networking working. * Here's what I've got installed: kernel-xen-guest-devel-2.6.15-1.43_FC5 xen-3.0-0.20060130.fc5.6 kernel-xen-hypervisor-devel-2.6.15-1.43_FC5 kernel-xen-hypervisor-devel-2.6.15-1.40_FC5 kernel-xen-guest-devel-2.6.15-1.40_FC5 kernel-xen-hypervisor-2.6.15-1.40_FC5 kernel-xen-guest-2.6.15-1.43_FC5 kernel-xen-guest-2.6.15-1.40_FC5 kernel-xen-hypervisor-2.6.15-1.43_FC5 * I'm booting the 2.6.15-1.43_FC5 hypervisor. * I scale the memory in Domain-0 down to 128M via xm mem-set Domain-0 128 (the machine has 512M total) * I run the newest xenguest-install.py from people.redhat.com. The memory is set to 256M, w/a 4G disk image. I'm pointing to a local ftp mirror of rawhide. * Installation starts and it asks for language & keyboard. * I let DHCP config the interface. * A quick window flashes (I can't read it -- its too fast), but about 3 or 4 minutes later I get a 'failed to connect to FTP server' message. * the firewall is turned off, but when the domU is running, there is a rule: Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-in vif2.0 * ip forwarding is turned on (echo 1 > /proc/sys/net/ipv4/ip_forward) * ifconfig -a looks like this: eth0 Link encap:Ethernet HWaddr 00:B0:D0:CE:CB:4E inet addr:129.79.32.152 Bcast:129.79.32.255 Mask:255.255.255.0 inet6 addr: 2001:18e8:2:32:2b0:d0ff:fece:cb4e/64 Scope:Global inet6 addr: fe80::2b0:d0ff:fece:cb4e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:25332 errors:0 dropped:0 overruns:0 frame:0 TX packets:2564 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:9050506 (8.6 MiB) TX bytes:359009 (350.5 KiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:32 errors:0 dropped:0 overruns:0 frame:0 TX packets:32 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2059 (2.0 KiB) TX bytes:2059 (2.0 KiB) peth0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link UP BROADCAST RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:29744 errors:0 dropped:0 overruns:2 frame:0 TX packets:2976 errors:0 dropped:0 overruns:0 carrier:0 collisions:88 txqueuelen:1000 RX bytes:10154374 (9.6 MiB) TX bytes:398012 (388.6 KiB) Interrupt:5 Base address:0xec00 sit0 Link encap:IPv6-in-IPv4 NOARP MTU:1480 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) veth1 Link encap:Ethernet HWaddr 00:00:00:00:00:00 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) veth2 Link encap:Ethernet HWaddr 00:00:00:00:00:00 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) veth3 Link encap:Ethernet HWaddr 00:00:00:00:00:00 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) veth4 Link encap:Ethernet HWaddr 00:00:00:00:00:00 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) veth5 Link encap:Ethernet HWaddr 00:00:00:00:00:00 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) veth6 Link encap:Ethernet HWaddr 00:00:00:00:00:00 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) veth7 Link encap:Ethernet HWaddr 00:00:00:00:00:00 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) vif0.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2564 errors:0 dropped:0 overruns:0 frame:0 TX packets:25341 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:359009 (350.5 KiB) TX bytes:9051241 (8.6 MiB) vif0.1 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) [ same for vif0.2 - vif0.7 ] vif2.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:37 errors:0 dropped:0 overruns:0 frame:0 TX packets:13777 errors:0 dropped:532 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3832 (3.7 KiB) TX bytes:1556351 (1.4 MiB) xenbr0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF inet6 addr: 2001:18e8:2:32:fcff:ffff:feff:ffff/64 Scope:Global inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:17361 errors:0 dropped:0 overruns:0 frame:0 TX packets:34 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1658926 (1.5 MiB) TX bytes:2924 (2.8 KiB) * brctl show displays this: bridge name bridge id STP enabled interfaces xenbr0 8000.feffffffffff no peth0 vif0.0 vif2.0 * the eth0 interface on Dom0 is dhcp generated, if that makes any difference. Any clues on what I'm missing? I'd guess that my ip for the Dom0 is on the wrong interface, but I'm not sure which one, or if that's even right. Thanks! Brian Wheeler bdwheele at indiana.edu From andy at warmcat.com Wed Feb 8 20:58:06 2006 From: andy at warmcat.com (Andy Green) Date: Wed, 08 Feb 2006 20:58:06 +0000 Subject: OLPC 'upstream' In-Reply-To: <20060208123206.6cf36eee.zaitcev@redhat.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> <1139384082.15809.2.camel@rousalka.dyndns.org> <1139384578.3579.39.camel@ender> <1139408681.2584.9.camel@dhcp83-115.boston.redhat.com> <43EA12A8.6060306@warmcat.com> <20060208123206.6cf36eee.zaitcev@redhat.com> Message-ID: <43EA5B5E.3070904@warmcat.com> Pete Zaitcev wrote: > On Wed, 08 Feb 2006 15:47:52 +0000, Andy Green wrote: > > >>Actually quite encouraging, we'll see if "busybox" and "newlib" or >>"uclibc" form part of Rehdat's concept. > > You must be raving mad to suggest uclibc. Was that supposed to be a > sarcastic pun on the miniscule RAM spec? What do you see shrivelling up and dying from contact with uclibc? I am using it here with good success, admittedly on a limited range of apps, but all stuff like coreutils and packages at that level like procps and so on are fine, as is openssl, php and lighttpd. What is your opinion about newlib? -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From zaitcev at redhat.com Wed Feb 8 21:05:38 2006 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 8 Feb 2006 13:05:38 -0800 Subject: OLPC 'upstream' In-Reply-To: <43EA5B5E.3070904@warmcat.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> <1139384082.15809.2.camel@rousalka.dyndns.org> <1139384578.3579.39.camel@ender> <1139408681.2584.9.camel@dhcp83-115.boston.redhat.com> <43EA12A8.6060306@warmcat.com> <20060208123206.6cf36eee.zaitcev@redhat.com> <43EA5B5E.3070904@warmcat.com> Message-ID: <20060208130538.1ab16e34.zaitcev@redhat.com> On Wed, 08 Feb 2006 20:58:06 +0000, Andy Green wrote: > Pete Zaitcev wrote: > > On Wed, 08 Feb 2006 15:47:52 +0000, Andy Green wrote: > > > >>Actually quite encouraging, we'll see if "busybox" and "newlib" or > >>"uclibc" form part of Rehdat's concept. > > > > You must be raving mad to suggest uclibc. Was that supposed to be a > > sarcastic pun on the miniscule RAM spec? > > What do you see shrivelling up and dying from contact with uclibc? I see now that you built Asterisk with it, so it cannot be all that bad. My experience may be stale. > What is your opinion about newlib? It's supposed to be better, but I do not have a personal exposure. -- Pete From nicolas.mailhot at laposte.net Wed Feb 8 21:14:06 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 08 Feb 2006 22:14:06 +0100 Subject: Request for testers: Video hardware autodetection In-Reply-To: <43E4A50E.5070209@mharris.ca> References: <43E4A50E.5070209@mharris.ca> Message-ID: <1139433246.2832.6.camel@rousalka.dyndns.org> Le samedi 04 f?vrier 2006 ? 07:58 -0500, Mike A. Harris a ?crit : > system-config-display --reconfig On this system system-config-display selects vesa instead of (correct) radeon driver 05:00.0 VGA compatible controller: ATI Technologies Inc RV410 [Radeon X700 (PCIE)] (prog-if 00 [VGA]) Subsystem: C.P. Technology Co. Ltd PowerColor Bravo X700 Flags: bus master, fast devsel, latency 0, IRQ 7 Memory at d0000000 (64-bit, prefetchable) [size=256M] Memory at e7000000 (64-bit, non-prefetchable) [size=64K] I/O ports at a000 [size=256] [virtual] Expansion ROM at e6000000 [disabled] [size=128K] Capabilities: 05:00.1 Display controller: ATI Technologies Inc RV410 [Radeon X700 (PCIE)] (Secondary) Subsystem: C.P. Technology Co. Ltd PowerColor Bravo X700 Flags: bus master, fast devsel, latency 0 Memory at e7010000 (64-bit, non-prefetchable) [size=64K] Capabilities: 05:00.0 0300: 1002:5e4d 05:00.1 0380: 1002:5e6d Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From andy at warmcat.com Wed Feb 8 21:16:46 2006 From: andy at warmcat.com (Andy Green) Date: Wed, 08 Feb 2006 21:16:46 +0000 Subject: OLPC 'upstream' In-Reply-To: <20060208123007.1f893b64.zaitcev@redhat.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> <1139384082.15809.2.camel@rousalka.dyndns.org> <1139384578.3579.39.camel@ender> <1139408681.2584.9.camel@dhcp83-115.boston.redhat.com> <43EA12A8.6060306@warmcat.com> <1139414570.17900.8.camel@dhcp83-115.boston.redhat.com> <43EA234B.2060601@warmcat.com> <5256d0b0602080916o13d09dc5r7d59101c8c6d0762@mail.gmail.com> <43EA2934.6020702@warmcat.com> <1139427443.3130.12.camel@daxter.boston.redhat.com> <20060208123007.1f893b64.zaitcev@redhat.com> Message-ID: <43EA5FBE.6030404@warmcat.com> Pete Zaitcev wrote: > Yes, it does. There's a very large number of shell snippets embedded > into applications. You may choose not to bundle gnome-terminal, that Hm yes also in RPM pre/post[un] > would be fine. But /bin/bash must be there and lame substitutions create > problems which are not worth the saved space. That is hard to be certain about without estimating some idea of the saved space, both in flash and in RAM. Ash is cut-down alright but the most-used features like if [ ] , while, for and the usual compare actions are in there and so on. Most intricate script activity is done by calling echo/cat/cut/grep/etc inside `` it seems It seems to me the biggest saving can be had with replacing many currently discrete packages with busybox. The busybox versions of everything are cut down... but... is that actually more of a bug than it is a feature is the question. Here is the canonical list of apps that can be generated inside the busybox binary, with implemented options: http://busybox.net/downloads/BusyBox.html As you scroll down the list of apps, think of all the packages that go out the window... Busybox has a Linux kernel-style make menuconfig where you can do finegrained enable and disable and config of the packages in it. If one particular thing is too weak, you can turn it off in Busybox and make it in its own package. Otherwise Busybox makes symlinks to itself in /bin/busybox for all the commands that it is compiled to support. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From dwmw2 at infradead.org Wed Feb 8 21:32:23 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 08 Feb 2006 21:32:23 +0000 Subject: OLPC 'upstream' In-Reply-To: <20060208170440.GA1460@devserv.devel.redhat.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> <1139384082.15809.2.camel@rousalka.dyndns.org> <1139384578.3579.39.camel@ender> <1139408681.2584.9.camel@dhcp83-115.boston.redhat.com> <43EA12A8.6060306@warmcat.com> <20060208170440.GA1460@devserv.devel.redhat.com> Message-ID: <1139434343.4183.22.camel@pmac.infradead.org> On Wed, 2006-02-08 at 12:04 -0500, Alan Cox wrote: > On Wed, Feb 08, 2006 at 03:47:52PM +0000, Andy Green wrote: > > requirements of mesh networking in combination with the abilities of the > > madwifi device driver have driven this selection; it is the best and > > most flexible wireless device driver today. There are not other viable > > alternatives at this time. > > Madwifi is not free software. Indeed. It would be entirely unacceptable to use the illegal madwifi HAL, and that fact has been made clear to all involved. Trust me :) -- dwmw2 From alan at redhat.com Wed Feb 8 21:41:54 2006 From: alan at redhat.com (Alan Cox) Date: Wed, 8 Feb 2006 16:41:54 -0500 Subject: OLPC 'upstream' In-Reply-To: <1139427443.3130.12.camel@daxter.boston.redhat.com> References: <1139369574.3279.34.camel@daxter.boston.redhat.com> <1139384082.15809.2.camel@rousalka.dyndns.org> <1139384578.3579.39.camel@ender> <1139408681.2584.9.camel@dhcp83-115.boston.redhat.com> <43EA12A8.6060306@warmcat.com> <1139414570.17900.8.camel@dhcp83-115.boston.redhat.com> <43EA234B.2060601@warmcat.com> <5256d0b0602080916o13d09dc5r7d59101c8c6d0762@mail.gmail.com> <43EA2934.6020702@warmcat.com> <1139427443.3130.12.camel@daxter.boston.redhat.com> Message-ID: <20060208214154.GA13014@devserv.devel.redhat.com> On Wed, Feb 08, 2006 at 02:37:23PM -0500, David Zeuthen wrote: > > Does this laptop really need a full bash? > Does this laptop really need a shell? The busybox and shell setup on the Nokia 770 rather proves the value of a shell I think. You don't need it, you can't even get at it without adding packages but it makes it possible to do many things. Shells are cheap (40-50K) unless you let the FSF near them From pjones at redhat.com Wed Feb 8 21:48:17 2006 From: pjones at redhat.com (Peter Jones) Date: Wed, 08 Feb 2006 16:48:17 -0500 Subject: dmraid comments and a warning In-Reply-To: <1139416647.15968.101.camel@localhost.localdomain> References: <1139256516.4440.66.camel@mentorng.gurulabs.com> <1139296637.3599.24.camel@mentorng.gurulabs.com> <1139351640.15968.68.camel@localhost.localdomain> <200602071622.42894.lamont@gurulabs.com> <1139414860.15968.98.camel@localhost.localdomain> <1139416647.15968.101.camel@localhost.localdomain> Message-ID: <1139435297.15968.110.camel@localhost.localdomain> On Wed, 2006-02-08 at 11:37 -0500, Peter Jones wrote: > On Wed, 2006-02-08 at 11:07 -0500, Peter Jones wrote: > > The patch adds a block device ioctl BLKRMPARTS, which simply turns all > > of the subdevices on a block device off. You can turn them back on with > > BLKRRPART, which is exposed to sysadmins via "/sbin/blockdev > > --rereadpt". I'll look at adding --rmparts to that utility as well. > > .. actually the patch may not be necessary, there's a way to remove > individual partitions elsewhere in the kernel, and that may be usable. > The functionality should probably still be added to /sbin/blockdev . OK, that should be in rawhide in the next couple of days. Hopefully tomorrow, but the build boxes are a little crowded recently. -- Peter From pemboa at gmail.com Wed Feb 8 21:58:16 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 8 Feb 2006 15:58:16 -0600 Subject: Fedora in need of testers? In-Reply-To: <986ed62e0602081156i79156d89u4251187d27c9541d@mail.gmail.com> References: <16de708d0512222319p3307eac0k476dc2b1b0a0a061@mail.gmail.com> <20051223074648.GA1842@tomservo.boston.redhat.com> <16de708d0602081100m8879378u91bea43fa892c79e@mail.gmail.com> <986ed62e0602081156i79156d89u4251187d27c9541d@mail.gmail.com> Message-ID: <16de708d0602081358t2f4fd4f8xc463ffc7672c6df@mail.gmail.com> On 2/8/06, Barry K. Nathan wrote: > > On 2/8/06, Arthur Pemberton wrote: > > How can I help with a lowly 500 MHz machine I have acquired? It wasn't > what > > I was expecting originally, but that's because my original plans fell > > through. > > As long as it has enough RAM (check the release notes) and some free > disk space, and as long as you have a little patience, it should be > fine for testing. > > I'm coming back to Fedora Core testing after a long break (for various > reasons)... with a 350MHz machine. ^_^ > -- > -Barry K. Nathan Inspiring, cool -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pemboa at gmail.com Wed Feb 8 21:59:20 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 8 Feb 2006 15:59:20 -0600 Subject: Fedora in need of testers? In-Reply-To: <200602081336.23788.lamont@gurulabs.com> References: <16de708d0512222319p3307eac0k476dc2b1b0a0a061@mail.gmail.com> <16de708d0602081100m8879378u91bea43fa892c79e@mail.gmail.com> <986ed62e0602081156i79156d89u4251187d27c9541d@mail.gmail.com> <200602081336.23788.lamont@gurulabs.com> Message-ID: <16de708d0602081359w83e1d21h6c7255aa123e5e2c@mail.gmail.com> On 2/8/06, Lamont R. Peterson wrote: > > On Wednesday 08 February 2006 12:56pm, Barry K. Nathan wrote: > > On 2/8/06, Arthur Pemberton wrote: > > > How can I help with a lowly 500 MHz machine I have acquired? It wasn't > > > what I was expecting originally, but that's because my original plans > > > fell through. > > > > As long as it has enough RAM (check the release notes) and some free > > disk space, and as long as you have a little patience, it should be > > fine for testing. > > > > I'm coming back to Fedora Core testing after a long break (for various > > reasons)... with a 350MHz machine. ^_^ > > I think having some slow machines in the mix is good. We don't want to be > building a distribution that suddenly only runs "tolerably" on "the last > 20% > of the speed curve" hardware. > > Then again, those with "only" slow machines need to be cautious of > becoming > "numb" about performance. After a while, you get used to the speed of > your > machine (screaming fast, painfully slow or anywhere in between) and it can > become very easy to overlook the changes in performance. I think the best > defense against that is awareness + hard numbers (benchmark). > > "time" is your friend :) . It turns fuzzy time into something that we can > all > talk about. > > So, to those with "slow" boxes; happy testing. Ok cool. I'll install FC4 on it this weekend. Any recommendations for DE, esp. as XFCE is no longer on the install media. My regular DE is KDE. P.S. I don't speak for the Fedora Project :) . > -- > Lamont R. Peterson > Senior Instructor > Guru Labs, L.C. [ http://www.GuruLabs.com/ ] > GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lamont at gurulabs.com Wed Feb 8 22:31:45 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Wed, 8 Feb 2006 15:31:45 -0700 Subject: Fedora in need of testers? In-Reply-To: <16de708d0602081359w83e1d21h6c7255aa123e5e2c@mail.gmail.com> References: <16de708d0512222319p3307eac0k476dc2b1b0a0a061@mail.gmail.com> <200602081336.23788.lamont@gurulabs.com> <16de708d0602081359w83e1d21h6c7255aa123e5e2c@mail.gmail.com> Message-ID: <200602081531.49233.lamont@gurulabs.com> On Wednesday 08 February 2006 02:59pm, Arthur Pemberton wrote: > On 2/8/06, Lamont R. Peterson wrote: [snip] > > I think having some slow machines in the mix is good. We don't want to > > be building a distribution that suddenly only runs "tolerably" on "the > > last 20% > > of the speed curve" hardware. > > > > Then again, those with "only" slow machines need to be cautious of > > becoming > > "numb" about performance. After a while, you get used to the speed of > > your > > machine (screaming fast, painfully slow or anywhere in between) and it > > can become very easy to overlook the changes in performance. I think the > > best defense against that is awareness + hard numbers (benchmark). > > > > "time" is your friend :) . It turns fuzzy time into something that we > > can all > > talk about. > > > > So, to those with "slow" boxes; happy testing. > > Ok cool. I'll install FC4 on it this weekend. Any recommendations for DE, > esp. as XFCE is no longer on the install media. My regular DE is KDE. I would either grab fluxbox (or friend of your choice) from extras or just go with KDE. It's not that heavy and testing to make sure it doesn't get "that" heavy (if you want to) can also be quite helpful. Either way, I would start with a minimal install and build up from there, testing those things you want to test. "yum install" is your friend. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wolverine_ at mac.com Wed Feb 8 22:47:25 2006 From: wolverine_ at mac.com (Adam Huda) Date: Wed, 8 Feb 2006 14:47:25 -0800 Subject: Testing Xen. Some quick questions. In-Reply-To: <1139414813.22826.19.camel@bree.local.net> References: <1139368548.2603.35.camel@dragon.sys.intra> <1139371661.2907.66.camel@bree.local.net> <1139376613.17114.37.camel@dragon.sys.intra> <04238730-1E23-4018-96E6-C3F31DD0A8D8@mac.com> <1139414813.22826.19.camel@bree.local.net> Message-ID: <5F88D770-1703-42D6-8302-061657A3C187@mac.com> Looks good now. Found this problem though: What is the name of your virtual machine? xenguest How much RAM should be allocated (in megabytes)? 256 What would you like to use as the disk (path)? /home/ahuda/xenguest How large would you like the disk to be (in gigabytes)? 4 Traceback (most recent call last): File "/usr/sbin/xenguest-install.py", line 357, in ? main() File "/usr/sbin/xenguest-install.py", line 347, in main src = get_paravirt_install(options) File "/usr/sbin/xenguest-install.py", line 223, in get_paravirt_install if src.startswith("http://") or src.startswith("ftp://"): AttributeError: 'NoneType' object has no attribute 'startswith' Also vmlinuz-2.6.15-1.43_FC5 hypervisor won't boot. It starts to boot and then the machine immediately restarts. Is there anyway I can figure out the actual error? I still haven't got a guest installed using the xenguest-install.py process. When the actual installation starts, it installs a few packages and then dies. -- Adam On Feb 8, 2006, at 8:06 AM, Jeremy Katz wrote: > On Tue, 2006-02-07 at 22:15 -0800, Adam Huda wrote: >> One suggestion for xenguest-install.py. You might want to set the >> initial value of ram to 256. It is a little confusing when it prints >> out "ERROR: Installs currently require 256 megs of RAM." in >> interactive mode (running without any command line args) before your >> prompted with "How much RAM should be allocated (in megabytes)? ". > > This should actually be handled better as of today's xen package > > Jeremy > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From katzj at redhat.com Wed Feb 8 23:04:54 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 08 Feb 2006 18:04:54 -0500 Subject: Testing Xen. Some quick questions. In-Reply-To: <5F88D770-1703-42D6-8302-061657A3C187@mac.com> References: <1139368548.2603.35.camel@dragon.sys.intra> <1139371661.2907.66.camel@bree.local.net> <1139376613.17114.37.camel@dragon.sys.intra> <04238730-1E23-4018-96E6-C3F31DD0A8D8@mac.com> <1139414813.22826.19.camel@bree.local.net> <5F88D770-1703-42D6-8302-061657A3C187@mac.com> Message-ID: <1139439894.15576.3.camel@bree.local.net> On Wed, 2006-02-08 at 14:47 -0800, Adam Huda wrote: > Found this problem though: [snip] > AttributeError: 'NoneType' object has no attribute 'startswith' Fixed this this afternoon. > Also vmlinuz-2.6.15-1.43_FC5 hypervisor won't boot. It starts to boot > and then the machine immediately restarts. Is there anyway I can > figure out the actual error? If you add noreboot to the xen line, it won't reboot. If you're on an smp box, you're probably hitting #180535. maxcpus=1 on the kernel line will work around and Rik is hot on the case. > I still haven't got a guest installed using the xenguest-install.py > process. When the actual installation starts, it installs a few > packages and then dies. Hrmm -- I haven't seen this. How does it die? Does the guest just hang or ... ? Jeremy From paul at cypherpunks.ca Thu Feb 9 00:06:15 2006 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 9 Feb 2006 01:06:15 +0100 (CET) Subject: Testing Xen. Some quick questions. In-Reply-To: <5F88D770-1703-42D6-8302-061657A3C187@mac.com> References: <1139368548.2603.35.camel@dragon.sys.intra> <1139371661.2907.66.camel@bree.local.net> <1139376613.17114.37.camel@dragon.sys.intra> <04238730-1E23-4018-96E6-C3F31DD0A8D8@mac.com> <1139414813.22826.19.camel@bree.local.net> <5F88D770-1703-42D6-8302-061657A3C187@mac.com> Message-ID: On Wed, 8 Feb 2006, Adam Huda wrote: > I still haven't got a guest installed using the xenguest-install.py > process. When the actual installation starts, it installs a few packages > and then dies. I am not entirely sure why people want to fake a netboot and go through anaconda. What is wrong with using yum with --installroot? dd if=/dev/zero of=fc4-i386.img bs=1M count=1 seek=4096 /sbin/mke2fs -F -j fc4-i386.img mount -o loop fc4-i386.img /mnt mkdir /mnt/dev mkdir /mnt/proc mkdir /mnt/etc for i in console null zero ; do /sbin/MAKEDEV -d /mnt/dev -x $i ; done cp projects/documentation/xen/fstab-xen /mnt/etc/fstab mount -t proc none /mnt/proc yum -c yum-xen.conf --installroot=/mnt -y groupinstall Base find /mnt/var/cache/yum -name \*.rpm | xargs rm mv /mnt/lib/tls /mnt/lib/tls-disabled sync (on fc3 I had to kill minilogd that got started as part of the install) umount /mnt/proc umount /mnt where fstab-xen is: /dev/hda1 / ext3 defaults 1 1 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 and yum-xen.conf: [main] cachedir=/var/cache/yum debuglevel=2 logfile=/var/log/yum.log exclude=*-debuginfo gpgcheck=0 obsoletes=1 reposdir=/dev/null [base] name=Fedora Core 4 - i386 - Base mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-4 enabled=1 [updates-released] name=Fedora Core 4 - i386 - Released Updates mirrorlist=http://fedora.redhat.com/download/mirrors/updates-released-fc4 enabled=1 That's how I've created my FC3 and FC4 images. I haven't had time to point one at FC5 yet, but I would assume that works as well? Paul From wolverine_ at mac.com Thu Feb 9 00:09:23 2006 From: wolverine_ at mac.com (Adam Huda) Date: Wed, 8 Feb 2006 16:09:23 -0800 Subject: Testing Xen. Some quick questions. In-Reply-To: <1139439894.15576.3.camel@bree.local.net> References: <1139368548.2603.35.camel@dragon.sys.intra> <1139371661.2907.66.camel@bree.local.net> <1139376613.17114.37.camel@dragon.sys.intra> <04238730-1E23-4018-96E6-C3F31DD0A8D8@mac.com> <1139414813.22826.19.camel@bree.local.net> <5F88D770-1703-42D6-8302-061657A3C187@mac.com> <1139439894.15576.3.camel@bree.local.net> Message-ID: <027CB7FB-842E-474C-89A3-1777DA45F389@mac.com> > If you add noreboot to the xen line, it won't reboot. If you're on an > smp box, you're probably hitting #180535. maxcpus=1 on the kernel > line > will work around and Rik is hot on the case. Thanks, maxcpus=1 did the trick. > Hrmm -- I haven't seen this. How does it die? Does the guest just > hang > or ... ? It hangs when it gets to the package: glibc-common-2.3.90-36: Common binaries and locale data for glibc Looking at xm top, no network traffic is flowing. On Feb 8, 2006, at 3:04 PM, Jeremy Katz wrote: > On Wed, 2006-02-08 at 14:47 -0800, Adam Huda wrote: >> Found this problem though: > [snip] >> AttributeError: 'NoneType' object has no attribute 'startswith' > > Fixed this this afternoon. > >> Also vmlinuz-2.6.15-1.43_FC5 hypervisor won't boot. It starts to boot >> and then the machine immediately restarts. Is there anyway I can >> figure out the actual error? > > If you add noreboot to the xen line, it won't reboot. If you're on an > smp box, you're probably hitting #180535. maxcpus=1 on the kernel > line > will work around and Rik is hot on the case. > >> I still haven't got a guest installed using the xenguest-install.py >> process. When the actual installation starts, it installs a few >> packages and then dies. > > Hrmm -- I haven't seen this. How does it die? Does the guest just > hang > or ... ? > > Jeremy > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From katzj at redhat.com Thu Feb 9 00:21:17 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 08 Feb 2006 19:21:17 -0500 Subject: Testing Xen. Some quick questions. In-Reply-To: References: <1139368548.2603.35.camel@dragon.sys.intra> <1139371661.2907.66.camel@bree.local.net> <1139376613.17114.37.camel@dragon.sys.intra> <04238730-1E23-4018-96E6-C3F31DD0A8D8@mac.com> <1139414813.22826.19.camel@bree.local.net> <5F88D770-1703-42D6-8302-061657A3C187@mac.com> Message-ID: <1139444477.15576.12.camel@bree.local.net> On Thu, 2006-02-09 at 01:06 +0100, Paul Wouters wrote: > On Wed, 8 Feb 2006, Adam Huda wrote: > > I still haven't got a guest installed using the xenguest-install.py > > process. When the actual installation starts, it installs a few packages > > and then dies. > > I am not entirely sure why people want to fake a netboot and go through > anaconda. What is wrong with using yum with --installroot? Because this 1) Requires a completely new set of tools for provisioning that is different from everything else you use 2) Requires a number of manual steps 3) Doesn't give good support for things like SELinux 4) Requires you to manage kernels for guests from the host. Which means you install some stuff to the guest, but the kernel you have to special case -- just weird Using anaconda is far, far nicer. Plus, it will continue to work as the distro changes instead of requiring changes to a weird set of steps. Jeremy From wolverine_ at mac.com Thu Feb 9 00:20:28 2006 From: wolverine_ at mac.com (Adam Huda) Date: Wed, 8 Feb 2006 16:20:28 -0800 Subject: Subject: Re: Testing Xen. Some quick questions. Message-ID: <85E120D6-48F8-46A7-850F-60531A3778F1@mac.com> > It hangs when it gets to the package: > > glibc-common-2.3.90-36: Common binaries and locale data for glibc > > Looking at xm top, no network traffic is flowing. > > I take that back. Now that I'm running vmlinuz-2.6.15-1.43_FC5hypervisor the install seems to be working. From katzj at redhat.com Thu Feb 9 00:22:04 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 08 Feb 2006 19:22:04 -0500 Subject: Testing Xen. Some quick questions. In-Reply-To: <027CB7FB-842E-474C-89A3-1777DA45F389@mac.com> References: <1139368548.2603.35.camel@dragon.sys.intra> <1139371661.2907.66.camel@bree.local.net> <1139376613.17114.37.camel@dragon.sys.intra> <04238730-1E23-4018-96E6-C3F31DD0A8D8@mac.com> <1139414813.22826.19.camel@bree.local.net> <5F88D770-1703-42D6-8302-061657A3C187@mac.com> <1139439894.15576.3.camel@bree.local.net> <027CB7FB-842E-474C-89A3-1777DA45F389@mac.com> Message-ID: <1139444524.15576.14.camel@bree.local.net> On Wed, 2006-02-08 at 16:09 -0800, Adam Huda wrote: > > Hrmm -- I haven't seen this. How does it die? Does the guest just > > hang or ... ? > It hangs when it gets to the package: > glibc-common-2.3.90-36: Common binaries and locale data for glibc > Looking at xm top, no network traffic is flowing. How much memory are you giving your guest? Jeremy From jos at xos.nl Thu Feb 9 00:20:58 2006 From: jos at xos.nl (Jos Vos) Date: Thu, 9 Feb 2006 01:20:58 +0100 Subject: Testing Xen. Some quick questions. In-Reply-To: ; from paul@cypherpunks.ca on Thu, Feb 09, 2006 at 01:06:15AM +0100 References: <1139368548.2603.35.camel@dragon.sys.intra> <1139371661.2907.66.camel@bree.local.net> <1139376613.17114.37.camel@dragon.sys.intra> <04238730-1E23-4018-96E6-C3F31DD0A8D8@mac.com> <1139414813.22826.19.camel@bree.local.net> <5F88D770-1703-42D6-8302-061657A3C187@mac.com> Message-ID: <20060209012058.E7700@xos037.xos.nl> On Thu, Feb 09, 2006 at 01:06:15AM +0100, Paul Wouters wrote: > I am not entirely sure why people want to fake a netboot and go through > anaconda. What is wrong with using yum with --installroot? Well, some things are not configured then, like - Network - Authentication - Firewall - Root password - Timezone - ... This is all easy to script, of course, if you know what you want, or can be done later, but some people may not want to find this out themselves (although we could extend the list by some commands like system-config-... to do these things later). > for i in console null zero ; do /sbin/MAKEDEV -d /mnt/dev -x $i ; done Note that I needed to add "tty" to this list *without* the -x, as otherwise the early boot stage - when /dev fs was not yet mounted - could not open tty1 etc. (but this was not on the latest Fedora, so this might be different for FC5). > mv /mnt/lib/tls /mnt/lib/tls-disabled Unless you use a glibc compiled with "-mno-tls-direct-seg-refs" (added to BuildFlags in the glibc spec file), recommended, AFAIK. B.t.w., what are the drawbacks of this? > (on fc3 I had to kill minilogd that got started as part of the install) Same here... -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From katzj at redhat.com Thu Feb 9 00:24:49 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 08 Feb 2006 19:24:49 -0500 Subject: Testing Xen. Some quick questions. In-Reply-To: <20060209012058.E7700@xos037.xos.nl> References: <1139368548.2603.35.camel@dragon.sys.intra> <1139371661.2907.66.camel@bree.local.net> <1139376613.17114.37.camel@dragon.sys.intra> <04238730-1E23-4018-96E6-C3F31DD0A8D8@mac.com> <1139414813.22826.19.camel@bree.local.net> <5F88D770-1703-42D6-8302-061657A3C187@mac.com> <20060209012058.E7700@xos037.xos.nl> Message-ID: <1139444690.15576.17.camel@bree.local.net> On Thu, 2006-02-09 at 01:20 +0100, Jos Vos wrote: > On Thu, Feb 09, 2006 at 01:06:15AM +0100, Paul Wouters wrote: > > mv /mnt/lib/tls /mnt/lib/tls-disabled > > Unless you use a glibc compiled with "-mno-tls-direct-seg-refs" > (added to BuildFlags in the glibc spec file), recommended, AFAIK. > B.t.w., what are the drawbacks of this? You lose decent threading (NPTL). Also, you can't do this with fc5 as glibc is always built for NPTL. But, there's the nosegneg glibc binaries included which get used automatically with Xen kernels so that you can get TLS without the downsides. This should work on FC4, too Jeremy From cmadams at hiwaay.net Thu Feb 9 00:26:43 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 8 Feb 2006 18:26:43 -0600 Subject: Testing Xen. Some quick questions. In-Reply-To: References: <1139368548.2603.35.camel@dragon.sys.intra> <1139371661.2907.66.camel@bree.local.net> <1139376613.17114.37.camel@dragon.sys.intra> <04238730-1E23-4018-96E6-C3F31DD0A8D8@mac.com> <1139414813.22826.19.camel@bree.local.net> <5F88D770-1703-42D6-8302-061657A3C187@mac.com> Message-ID: <20060209002643.GE1554089@hiwaay.net> Once upon a time, Paul Wouters said: > I am not entirely sure why people want to fake a netboot and go through > anaconda. What is wrong with using yum with --installroot? yum installs a bunch of packages; anaconda builds a system (there's a difference). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jos at xos.nl Thu Feb 9 00:30:05 2006 From: jos at xos.nl (Jos Vos) Date: Thu, 9 Feb 2006 01:30:05 +0100 Subject: Testing Xen. Some quick questions. In-Reply-To: <1139444690.15576.17.camel@bree.local.net>; from katzj@redhat.com on Wed, Feb 08, 2006 at 07:24:49PM -0500 References: <1139368548.2603.35.camel@dragon.sys.intra> <1139371661.2907.66.camel@bree.local.net> <1139376613.17114.37.camel@dragon.sys.intra> <04238730-1E23-4018-96E6-C3F31DD0A8D8@mac.com> <1139414813.22826.19.camel@bree.local.net> <5F88D770-1703-42D6-8302-061657A3C187@mac.com> <20060209012058.E7700@xos037.xos.nl> <1139444690.15576.17.camel@bree.local.net> Message-ID: <20060209013005.A7953@xos037.xos.nl> On Wed, Feb 08, 2006 at 07:24:49PM -0500, Jeremy Katz wrote: > On Thu, 2006-02-09 at 01:20 +0100, Jos Vos wrote: > > Unless you use a glibc compiled with "-mno-tls-direct-seg-refs" > > (added to BuildFlags in the glibc spec file), recommended, AFAIK. > > B.t.w., what are the drawbacks of this? > > You lose decent threading (NPTL). Also, you can't do this with fc5 as But not with the "-mno-tls-...", right? I was asking for the drawbacks of using glibc compiled with this flag: so, why is glibc only generated that way for use with Xen? -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From katzj at redhat.com Thu Feb 9 00:43:21 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 08 Feb 2006 19:43:21 -0500 Subject: Testing Xen. Some quick questions. In-Reply-To: <20060209013005.A7953@xos037.xos.nl> References: <1139368548.2603.35.camel@dragon.sys.intra> <1139371661.2907.66.camel@bree.local.net> <1139376613.17114.37.camel@dragon.sys.intra> <04238730-1E23-4018-96E6-C3F31DD0A8D8@mac.com> <1139414813.22826.19.camel@bree.local.net> <5F88D770-1703-42D6-8302-061657A3C187@mac.com> <20060209012058.E7700@xos037.xos.nl> <1139444690.15576.17.camel@bree.local.net> <20060209013005.A7953@xos037.xos.nl> Message-ID: <1139445802.15576.21.camel@bree.local.net> On Thu, 2006-02-09 at 01:30 +0100, Jos Vos wrote: > On Wed, Feb 08, 2006 at 07:24:49PM -0500, Jeremy Katz wrote: > > > On Thu, 2006-02-09 at 01:20 +0100, Jos Vos wrote: > > > > Unless you use a glibc compiled with "-mno-tls-direct-seg-refs" > > > (added to BuildFlags in the glibc spec file), recommended, AFAIK. > > > B.t.w., what are the drawbacks of this? > > > > You lose decent threading (NPTL). Also, you can't do this with fc5 as > > But not with the "-mno-tls-...", right? I was asking for the drawbacks > of using glibc compiled with this flag: so, why is glibc only generated > that way for use with Xen? ISTR there being a performance difference Jeremy From zaitcev at redhat.com Thu Feb 9 00:47:55 2006 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 8 Feb 2006 16:47:55 -0800 Subject: OLPC 'upstream' In-Reply-To: <43EA5FBE.6030404@warmcat.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> <1139384082.15809.2.camel@rousalka.dyndns.org> <1139384578.3579.39.camel@ender> <1139408681.2584.9.camel@dhcp83-115.boston.redhat.com> <43EA12A8.6060306@warmcat.com> <1139414570.17900.8.camel@dhcp83-115.boston.redhat.com> <43EA234B.2060601@warmcat.com> <5256d0b0602080916o13d09dc5r7d59101c8c6d0762@mail.gmail.com> <43EA2934.6020702@warmcat.com> <1139427443.3130.12.camel@daxter.boston.redhat.com> <20060208123007.1f893b64.zaitcev@redhat.com> <43EA5FBE.6030404@warmcat.com> Message-ID: <20060208164755.291f8d60.zaitcev@redhat.com> On Wed, 08 Feb 2006 21:16:46 +0000, Andy Green wrote: > > would be fine. But /bin/bash must be there and lame substitutions create > > problems which are not worth the saved space. > > That is hard to be certain about without estimating some idea of the > saved space, both in flash and in RAM. Ash is cut-down alright but the > most-used features like if [ ] , while, for and the usual compare > actions are in there and so on. Most intricate script activity is done > by calling echo/cat/cut/grep/etc inside `` it seems Very well, if you say so, ash may be all right. But busybox seems to take this too far. You know what the root of all evil is... So why don't we let OLPC group to actually build a system and take measurements? It seems too early to decide on busybox. For crying out loud, it's a system with GNOME. I'm sure 10 core systems can disappear in the noise of that set of packages. :-) -- Pete From wolverine_ at mac.com Thu Feb 9 01:12:58 2006 From: wolverine_ at mac.com (Adam Huda) Date: Wed, 8 Feb 2006 17:12:58 -0800 Subject: Testing Xen. Some quick questions. In-Reply-To: <1139444524.15576.14.camel@bree.local.net> References: <1139368548.2603.35.camel@dragon.sys.intra> <1139371661.2907.66.camel@bree.local.net> <1139376613.17114.37.camel@dragon.sys.intra> <04238730-1E23-4018-96E6-C3F31DD0A8D8@mac.com> <1139414813.22826.19.camel@bree.local.net> <5F88D770-1703-42D6-8302-061657A3C187@mac.com> <1139439894.15576.3.camel@bree.local.net> <027CB7FB-842E-474C-89A3-1777DA45F389@mac.com> <1139444524.15576.14.camel@bree.local.net> Message-ID: I gave the guest 256 MB. My machine has 2 GB. Under 2.6.15-1.40_FC5hypervisor I tried setting: xm mem-max 512 0 xm mem-set 512 0 Then when starting anaconda, I got some error about the net driver having to squeeze memory (sorry about being hazing on the exact error, I can reproduce it later if you like) when getting an IP via DHCP and at which point the install would break. With the latest xen hypervisor (43), I'm not having any problems with the anaconda install. I just finished a rawhide guest installation and rebooted the guest. However, the pygrub boot loader is giving me some problems when I try to start the guest: [root at localhost ~]# xm create -c rawhide Using config file "/etc/xen/rawhide". Traceback (most recent call last): File "/usr/bin/pygrub", line 246, in ? cf = get_config(file) File "/usr/bin/pygrub", line 123, in get_config raise RuntimeError, "we couldn't find /boot/grub {menu.lst,grub.conf} " + \ RuntimeError: we couldn't find /boot/grub{menu.lst,grub.conf} in the image provided. halt! Error: Boot loader didn't return any data! I haven't had a chance to dig around this yet. -- Adam On Feb 8, 2006, at 4:22 PM, Jeremy Katz wrote: > On Wed, 2006-02-08 at 16:09 -0800, Adam Huda wrote: >>> Hrmm -- I haven't seen this. How does it die? Does the guest just >>> hang or ... ? >> It hangs when it gets to the package: >> glibc-common-2.3.90-36: Common binaries and locale data for glibc >> Looking at xm top, no network traffic is flowing. > > How much memory are you giving your guest? > > Jeremy > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From naoki at valuecommerce.com Thu Feb 9 02:56:05 2006 From: naoki at valuecommerce.com (Naoki) Date: Thu, 09 Feb 2006 11:56:05 +0900 Subject: Linux-HA? Message-ID: <1139453765.17114.103.camel@dragon.sys.intra> Hey all, Does Fedora plan on shipping Linux-HA ( heartbeat )? Or is there a replacement / similar package which is otherwise recommended ? From tburke at redhat.com Thu Feb 9 03:07:57 2006 From: tburke at redhat.com (Tim Burke) Date: Wed, 08 Feb 2006 22:07:57 -0500 Subject: Linux-HA? In-Reply-To: <1139453765.17114.103.camel@dragon.sys.intra> References: <1139453765.17114.103.camel@dragon.sys.intra> Message-ID: <43EAB20D.3060703@redhat.com> Naoki wrote: >Hey all, > >Does Fedora plan on shipping Linux-HA ( heartbeat )? Or is there a >replacement / similar package which is otherwise recommended ? > > > Heartbeat isn't in extras. Rather, there is the "Red Hat Cluster Suite". This provides more than just the simple capabilities of heartbeat. It includes the host membership, ability to designate resources (ie applications start/stop as well as startup config like mounts & IP addresses). There's even a config GUI to setup and monitor. Information can be found on it by going to the search field on fedoraproject.org and entering gfs. The cluster suite is a sub-component of GFS. From admin at ramshacklestudios.com Thu Feb 9 05:26:41 2006 From: admin at ramshacklestudios.com (Peter Gordon) Date: Wed, 08 Feb 2006 21:26:41 -0800 Subject: [Fwd: Re: rawhide report: 20060207 changes] In-Reply-To: <43E9C8B1.7040707@mharris.ca> References: <43E9B689.6050203@mharris.ca> <43E9C8B1.7040707@mharris.ca> Message-ID: <1139462801.16833.3.camel@tuxhugger> On Wed, 2006-02-08 at 05:32 -0500, Mike A. Harris wrote: > 4) Having uol.com.br blacklisted via the MTA by the admin of my > domain. That's what I did. I set up a filter (through my server's cPanel interface) that simply discards everything whose "From:" header contains "@sspam.uol.com.br". I find such behaviour downright rude and *very* inconsiderate... -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xDA3634D7 Fingerprint: 0629 F604 3C14 937E F088 E5E9 B3CB 48EC DA36 34D7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From naoki at valuecommerce.com Thu Feb 9 06:02:44 2006 From: naoki at valuecommerce.com (Naoki) Date: Thu, 09 Feb 2006 15:02:44 +0900 Subject: Linux-HA? (Now with cluster questions!). In-Reply-To: <43EAB20D.3060703@redhat.com> References: <1139453765.17114.103.camel@dragon.sys.intra> <43EAB20D.3060703@redhat.com> Message-ID: <1139464964.17114.159.camel@dragon.sys.intra> On Wed, 2006-02-08 at 22:07 -0500, Tim Burke wrote: > Naoki wrote: > > >Hey all, > > > >Does Fedora plan on shipping Linux-HA ( heartbeat )? Or is there a > >replacement / similar package which is otherwise recommended ? > > > > > > > Heartbeat isn't in extras. Rather, there is the "Red Hat Cluster > Suite". This provides more than just the simple capabilities of > heartbeat. It includes the host membership, ability to designate > resources (ie applications start/stop as well as startup config like > mounts & IP addresses). There's even a config GUI to setup and monitor. > > Information can be found on it by going to the search field on > fedoraproject.org and entering gfs. The cluster suite is a > sub-component of GFS. Cheers. GFS/Cluster Suite is a bit over the top for a simple case of bringing up an IP and starting Apache, which is all I'm looking at doing. Seems like most other distros ship heartbeat for this type of basic job. Would anybody object to it being added to extras, does it conflict at all? While we're on the subject of clusters though (warning, maybe off topic a bit) .. ;) I'm a lot less interested in GFS as I am in seeing 2.6.16 kernel with OCFS2. >From fedoraproject.org : Red Hat GFS is... * The only native 64-bit cluster file system on Linux for enterprise workloads - support for x86, AMD64/EM64T, and Itanium * The most scalable enterprise cluster file system on Linux - supported up to 256 nodes * Tightly integrated with Fedora and Red Hat Enterprise Linux (no patching needed) * The only open source (GPL) cluster file system for enterprise workloads * POSIX-compliant, meaning applications don't have to be rewritten to use GFS I would argue the first, third, and fourth points are arguable at best and really just marketing speak rather than providing any sort of technical information. As for points two and five : OCFS2 also handles 256 nodes, but it's only a software limit and not a design limit. Last but not least, POSIX compliance, very important! OCFS2 is posix compliant as well. While this is in no way intended to be flame bait, IMHO in some cases GFS is not as good as OCFS2, and they are mainly comparable in features, yet OCFS2 seems to me to have little traction here on fedora-devel so I'm curious. For more reading : http://oss.oracle.com/projects/ocfs2/dist/documentation/ocfs2-whats-new.txt I guess my overly long post boils down to two questions, do we as a group like OCFS2? And, do we have/want a simple solution for basic HA (failovers etc) ? From andy at warmcat.com Thu Feb 9 11:11:28 2006 From: andy at warmcat.com (Andy Green) Date: Thu, 09 Feb 2006 11:11:28 +0000 Subject: OLPC 'upstream' In-Reply-To: <20060208164755.291f8d60.zaitcev@redhat.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> <1139384082.15809.2.camel@rousalka.dyndns.org> <1139384578.3579.39.camel@ender> <1139408681.2584.9.camel@dhcp83-115.boston.redhat.com> <43EA12A8.6060306@warmcat.com> <1139414570.17900.8.camel@dhcp83-115.boston.redhat.com> <43EA234B.2060601@warmcat.com> <5256d0b0602080916o13d09dc5r7d59101c8c6d0762@mail.gmail.com> <43EA2934.6020702@warmcat.com> <1139427443.3130.12.camel@daxter.boston.redhat.com> <20060208123007.1f893b64.zaitcev@redhat.com> <43EA5FBE.6030404@warmcat.com> <20060208164755.291f8d60.zaitcev@redhat.com> Message-ID: <43EB2360.7030308@warmcat.com> Pete Zaitcev wrote: > Very well, if you say so, ash may be all right. But busybox seems to > take this too far. You know what the root of all evil is... So why don't > we let OLPC group to actually build a system and take measurements? > It seems too early to decide on busybox. For crying out loud, it's That CPU has only 16K + 16K I/D cache. The AT91RM9200 embedded chip I use at the moment has the same cache :-O. It does have 64-bit path to its DRAM, but still, cache locality is going to be really critical. And that suggests you need an extreme War On Bloat: - because the less going through the small caches the less wasted CPU cycles waiting on DRAM - the less thrashed back and forth between the caches and the DRAM the faster and better power efficiency - because you have to suck it out the NAND flash and decompress it, the smaller the apps and libs the more responsive the system - because you may not have the flash you think you will --> Having stared at the spec, it is still the first and arguably only place cost reduction can happen, so it should be expected, in fact since I heard it had 1GB of flash that has already softened to "512M and maybe 1GB". In fact when people are desperate to save cents on the box you may end up with 64MB or less of flash onboard for the OS and be expected to use a USB flash pen to hold the actual usermode apps, if it lets them ship at the pricepoint. > a system with GNOME. I'm sure 10 core systems can disappear in the > noise of that set of packages. :-) I'm not sure how much of Gnome is planned to be in there as opposed to GTK2. Besides its not the way to get a tight system to say that other things are huge so everything can stay as in Desktop Fedora. Coming from embedded it seems to me the challenge of this game is not understood well yet. Fit the whole OS and X and toolkits in 20MB, not 200MB. Anyway I see the main need right now is to ship a 0.1 version as you suggest. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From russell at coker.com.au Thu Feb 9 11:33:25 2006 From: russell at coker.com.au (Russell Coker) Date: Thu, 9 Feb 2006 22:33:25 +1100 Subject: auid Message-ID: <200602092233.35511.russell@coker.com.au> I was talking to Wietse Venema about SE Linux and related things. He suggested that we consider doing what the C2 pack for SunOS apparently used to do (and what presumably some module of Trusted Solaris still does) in regard to the auid. In the SunOS case it was apparently impossible to reset the auid, not even root can do so. Of course this gives the problem of what happens when you restart sshd or crond, those programs would then be unable to set the auid. In Fedora we have gdm started from init, so restarting gdm is possible without auid issues in this regard. As we have the precedent with this daemon (which incidentally most other distributions seem to start from an /etc/init.d script) it doesn't seem unreasonable to me for "sshd -D" to also be run from init, and modifying crond to also support a -D option would not be difficult. Of course then we have the issue of other programs such as mail servers which perform actions on behalf of users but which should not be started from init. The next possibility that occurred to me is to have SE Linux control setting and resetting the auid. Then when the administrator starts the mail server the auid could be reset but when a mail server process is delivering mail and sets the auid it would not be able to do so. Even that seems inadequate in some ways. Another possibility that occurred to me is to have the auid field be an append-only text field. Therefore every audit record would have the chain of UIDs used back to when things were started by the kernel. In this case you might have auid=-1:500:0:501 to indicate that the user with UID 500 logged in to the system, run su or sudo to get uid 0 (or some other method) and then transitioned to uid 501 to perform the action in question. If the program which had the action logged was part of a MTA then that might indicate the mailer daemon being started by user 500 via sudo which then delivered mail to user 501. -- 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 Thu Feb 9 12:49:05 2006 From: alan at redhat.com (Alan Cox) Date: Thu, 9 Feb 2006 07:49:05 -0500 Subject: OLPC 'upstream' In-Reply-To: <43EB2360.7030308@warmcat.com> References: <43EA12A8.6060306@warmcat.com> <1139414570.17900.8.camel@dhcp83-115.boston.redhat.com> <43EA234B.2060601@warmcat.com> <5256d0b0602080916o13d09dc5r7d59101c8c6d0762@mail.gmail.com> <43EA2934.6020702@warmcat.com> <1139427443.3130.12.camel@daxter.boston.redhat.com> <20060208123007.1f893b64.zaitcev@redhat.com> <43EA5FBE.6030404@warmcat.com> <20060208164755.291f8d60.zaitcev@redhat.com> <43EB2360.7030308@warmcat.com> Message-ID: <20060209124905.GA19767@devserv.devel.redhat.com> On Thu, Feb 09, 2006 at 11:11:28AM +0000, Andy Green wrote: > That CPU has only 16K + 16K I/D cache. The AT91RM9200 embedded chip I > use at the moment has the same cache :-O. It does have 64-bit path to > its DRAM, but still, cache locality is going to be really critical. 12K, 4K of the 16K D cache vanishes mysteriously as the blitter when in graphics mode. Also the RAM is shared with the video and although the video fetch is usually RLE encoded on that chip it still hurts, especially with funky shading and backgrounds. > I'm not sure how much of Gnome is planned to be in there as opposed to > GTK2. Besides its not the way to get a tight system to say that other > things are huge so everything can stay as in Desktop Fedora. I see no point in running Gnome on such a device. Its way way too bloated and slow in its current form, and also has heavy FPU dependancies which aren't good on this device. From dwmw2 at infradead.org Thu Feb 9 12:49:57 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 09 Feb 2006 12:49:57 +0000 Subject: OLPC + Fedora = ? In-Reply-To: <43E87240.9010204@warmcat.com> References: <43E87240.9010204@warmcat.com> Message-ID: <1139489397.4183.61.camel@pmac.infradead.org> On Tue, 2006-02-07 at 10:11 +0000, Andy Green wrote: > Seems hard to believe that with such a low price point, AMD will deliver > optimal pricing and that the target CPU throughput is not excessive with > x86. Isn't it better for the longer term to only weakly couple the > concept of the cheap laptop to a processor arch? The choice of i386 was apparently largely influenced by the availability of a real FPU; something which wasn't really available in the same price/performance range on other embedded CPUs that were considered. -- dwmw2 From alan at redhat.com Thu Feb 9 12:50:43 2006 From: alan at redhat.com (Alan Cox) Date: Thu, 9 Feb 2006 07:50:43 -0500 Subject: auid In-Reply-To: <200602092233.35511.russell@coker.com.au> References: <200602092233.35511.russell@coker.com.au> Message-ID: <20060209125043.GB19767@devserv.devel.redhat.com> On Thu, Feb 09, 2006 at 10:33:25PM +1100, Russell Coker wrote: > to do (and what presumably some module of Trusted Solaris still does) in > regard to the auid. In the SunOS case it was apparently impossible to reset > the auid, not even root can do so. Same with the luid on trusted Unix like old SCO. > Of course this gives the problem of what happens when you restart sshd or > crond, those programs would then be unable to set the auid. In Fedora we You ask a daemon to restart them. In the old days of course init managed it all off inittab so the problem didnt arise. > Of course then we have the issue of other programs such as mail servers which > perform actions on behalf of users but which should not be started from init. It is performing actions _for_ that user. They are if you like the "billable entity" From andy at warmcat.com Thu Feb 9 13:11:35 2006 From: andy at warmcat.com (Andy Green) Date: Thu, 09 Feb 2006 13:11:35 +0000 Subject: OLPC 'upstream' In-Reply-To: <20060209124905.GA19767@devserv.devel.redhat.com> References: <43EA12A8.6060306@warmcat.com> <1139414570.17900.8.camel@dhcp83-115.boston.redhat.com> <43EA234B.2060601@warmcat.com> <5256d0b0602080916o13d09dc5r7d59101c8c6d0762@mail.gmail.com> <43EA2934.6020702@warmcat.com> <1139427443.3130.12.camel@daxter.boston.redhat.com> <20060208123007.1f893b64.zaitcev@redhat.com> <43EA5FBE.6030404@warmcat.com> <20060208164755.291f8d60.zaitcev@redhat.com> <43EB2360.7030308@warmcat.com> <20060209124905.GA19767@devserv.devel.redhat.com> Message-ID: <43EB3F87.10405@warmcat.com> Alan Cox wrote: > On Thu, Feb 09, 2006 at 11:11:28AM +0000, Andy Green wrote: >> That CPU has only 16K + 16K I/D cache. The AT91RM9200 embedded chip I >> use at the moment has the same cache :-O. It does have 64-bit path to >> its DRAM, but still, cache locality is going to be really critical. > > 12K, 4K of the 16K D cache vanishes mysteriously as the blitter when in > graphics mode. Also the RAM is shared with the video and although the video > fetch is usually RLE encoded on that chip it still hurts, especially with > funky shading and backgrounds. Is that actually true for this "AMD Geode? GX 500 at 1.0W" device variant? It says on p17 of the GX databook PDF that the GX1 type did have BLT Buffers "In Cacahe Scratchpad RAM", but it says that for the GX500 variant being specified at the moment, BLT Buffers are "FIFOs in GP". It also says above ''... The Graphics Processor is compatible with the graphics processor used in the GX1 processor with additional functions and features to improve performance and ease of use. Like its predecessor, the Geode GX processor?s Graphics Processor is a BitBLT/vector engine that supports pattern generation, source expansion, pattern/source transparency, and 256 ternary raster operations. New features that have been added to the Graphics Processor include: ? A 32-bit datapath that can support 32-bit ARGB full color. ? Incorporated BLT FIFOs to replace the cache based BLT buffers used in the GX1 processor. ? Improved bus protocols to increase bandwidth to the memory controller. ? The ability to throttle BLTs according to video timing and VGA hardware. ...'' If true that's good news, because losing the cache wouldn't help video playback. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From tburke at redhat.com Thu Feb 9 13:21:55 2006 From: tburke at redhat.com (Tim Burke) Date: Thu, 09 Feb 2006 08:21:55 -0500 Subject: Linux-HA? (Now with cluster questions!). In-Reply-To: <1139464964.17114.159.camel@dragon.sys.intra> References: <1139453765.17114.103.camel@dragon.sys.intra> <43EAB20D.3060703@redhat.com> <1139464964.17114.159.camel@dragon.sys.intra> Message-ID: <43EB41F3.40803@redhat.com> Naoki wrote: > >Cheers. GFS/Cluster Suite is a bit over the top for a simple case of >bringing up an IP and starting Apache, which is all I'm looking at >doing. Seems like most other distros ship heartbeat for this type of >basic job. Would anybody object to it being added to extras, does it >conflict at all? > > > Ah.... allow me to clarify... I understand your concern and agree that GFS is overkill for a simple failover apache config. The Cluster Suite stuff is bundled up with the GFS stuff, but can be used independently. Its perfectly well suited to apache failover, and the documentation is very thorough on how to do this. You don't need to setup GFS in this config. From alan at redhat.com Thu Feb 9 13:31:50 2006 From: alan at redhat.com (Alan Cox) Date: Thu, 9 Feb 2006 08:31:50 -0500 Subject: OLPC 'upstream' In-Reply-To: <43EB3F87.10405@warmcat.com> References: <43EA234B.2060601@warmcat.com> <5256d0b0602080916o13d09dc5r7d59101c8c6d0762@mail.gmail.com> <43EA2934.6020702@warmcat.com> <1139427443.3130.12.camel@daxter.boston.redhat.com> <20060208123007.1f893b64.zaitcev@redhat.com> <43EA5FBE.6030404@warmcat.com> <20060208164755.291f8d60.zaitcev@redhat.com> <43EB2360.7030308@warmcat.com> <20060209124905.GA19767@devserv.devel.redhat.com> <43EB3F87.10405@warmcat.com> Message-ID: <20060209133150.GA5902@devserv.devel.redhat.com> On Thu, Feb 09, 2006 at 01:11:35PM +0000, Andy Green wrote: > Buffers "In Cacahe Scratchpad RAM", but it says that for the GX500 > variant being specified at the moment, BLT Buffers are "FIFOs in GP". > It also says above Not 100% sure. > ? A 32-bit datapath that can support 32-bit ARGB full > color. Thats actually the important but unsupported by X bit right now. Its got render acceleration so can support EXA which is important for compositing and friends. > ? Incorporated BLT FIFOs to replace the cache based > BLT buffers used in the GX1 processor. Sounds promising > If true that's good news, because losing the cache wouldn't help video > playback. The Geode is not bad at video because it does have hardware colour conversion and scaling overlay logic in most variants of the support chip. Alan From kloczek at zie.pg.gda.pl Thu Feb 9 13:15:21 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=) Date: Thu, 09 Feb 2006 14:15:21 +0100 Subject: initscripts-8.26-1 breaks old alias interface naming scheme Message-ID: <1139490921.3532.9.camel@kloczek01.pracownicy.zie> Today I discover new initscripts-8.26-1 breaks old network alias interfaces naming scheme. In previouse version was powinble name alias interface like eth0:foobar In current iniscritps in /etc/sysconfig/network-scripts/ifup-aliases is: if [[ ! "$DEVNUM" =~ '^[0123456789]*$' ]]; then echo $"error in $FILE: invalid alias number" >&2 return 1 fi I think it can break many systems on upgrade to FC5. After commenting above old initscripts behavior is sill workig correctly. kloczek From linux_4ever at yahoo.com Thu Feb 9 13:39:25 2006 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 9 Feb 2006 05:39:25 -0800 (PST) Subject: auid In-Reply-To: <200602092233.35511.russell@coker.com.au> Message-ID: <20060209133925.28318.qmail@web51513.mail.yahoo.com> Hi Russell, This discussion is probably best held on the linux-audit mail list since you are possibly suggesting changing the behavior of the audit system. http://www.redhat.com/mailman/listinfo/linux-audit >He suggested that we consider doing what the C2 pack for SunOS apparently >used to do (and what presumably some module of Trusted Solaris still does) in >regard to the auid. Why? The current design is that only entry point programs set the login uid (auid). It works per the design. I don't really understand what problem you see. >In the SunOS case it was apparently impossible to reset the auid, not even root >can do so. Setting the login uid is supposed to be protected by SE Linux policy so that only the right apps can do it. In this whole email, you never specified what problem you see. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From dhollis at davehollis.com Thu Feb 9 14:05:55 2006 From: dhollis at davehollis.com (David Hollis) Date: Thu, 09 Feb 2006 09:05:55 -0500 Subject: Linux-HA? In-Reply-To: <1139453765.17114.103.camel@dragon.sys.intra> References: <1139453765.17114.103.camel@dragon.sys.intra> Message-ID: <1139493955.2717.14.camel@dhollis-lnx.sunera.com> On Thu, 2006-02-09 at 11:56 +0900, Naoki wrote: > Hey all, > > Does Fedora plan on shipping Linux-HA ( heartbeat )? Or is there a > replacement / similar package which is otherwise recommended ? If you do want to use heartbeat, it includes a working spec file in the tar.gz so you can build your own RPM with 'rpmbuild -ta heartbeat-1.0.5.tar.gz' or the like. Wouldn't be bad to be in extras though, it is quite useful and isn't big or require a boatload of dependencies. -- David 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 buildsys at redhat.com Thu Feb 9 15:07:51 2006 From: buildsys at redhat.com (Build System) Date: Thu, 9 Feb 2006 10:07:51 -0500 Subject: rawhide report: 20060209 changes (part 1/2) Message-ID: <200602091507.k19F7p2g012345@porkchop.devel.redhat.com> New package libstdc++so7 libstdc++.so.7 preview Updated Packages: ElectricFence-2.2.2-20.2 ------------------------ * Tue Feb 07 2006 Jesse Keating - 2.2.2-20.2 - rebuilt for new gcc4.1 snapshot and glibc changes GConf-1.0.9-18.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 1.0.9-18.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Thu Dec 15 2005 Ray Strode 1.0.9-18 - take ownership of directories that belong to the package (bug 151360) * Fri Dec 09 2005 Jesse Keating - rebuilt GConf2-2.13.5-3.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 2.13.5-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes GFS-6.1.4-0.FC5.1.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 6.1.4-0.FC5.1.1 - rebuilt for new gcc4.1 snapshot and glibc changes Guppi-0.40.3-24.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 0.40.3-24.2 - rebuilt for new gcc4.1 snapshot and glibc changes HelixPlayer-1:1.0.6-1.2 ----------------------- * Tue Feb 07 2006 Jesse Keating - 1:1.0.6-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes ImageMagick-6.2.5.4-4.1 ----------------------- * Tue Feb 07 2006 Jesse Keating - 6.2.5.4-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Mon Jan 30 2006 Matthias Clasen 6.2.5.4-4 - Make -devel require lcms-devel (#179200) agg-2.3-2 --------- anaconda-10.91.17-1 ------------------- * Wed Feb 08 2006 Paul Nasrat - 10.91.17-1 - Handle bind mounts correctly (#160911, dcantrel) - Upgrade package black list and make upgrades work - Disable repo conf for now - loader debuginfo - kickstart - suggest fix (#174597, clumens) anacron-2.3-36 -------------- * Tue Feb 07 2006 Jason Vas Dias - 2.3-36 - rebuild for new gcc, glibc, glibc-kernheaders arts-8:1.5.1-1.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 8:1.5.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes at-3.1.8-81 ----------- * Tue Feb 07 2006 Jason Vas Dias - 3.1.8-81 - rebuild for new gcc, glibc, glibc-kernheaders - workaround new refusal of /usr/bin/install to chown * Sun Dec 18 2005 Jason Vas Dias - 3.1.8-80.2 - rebuild for new flex * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj audit-1.1.4-1 ------------- * Wed Feb 08 2006 Steve Grubb 1.1.4-1 - Fix bug in autrace where it didn't run on kernels without file watch support - Add syslog message to auditd saying what program was started for dispatcher - Remove audit_send_user from public api - Fix bug in USER_LOGIN messages where ausearch does not translate msg='uid=500: into acct name (#178102). - Change comm with dispatcher to socketpair from pipe - Change auditd to use custom daemonize to avoid race in init scripts - Update error message when deleting a rule that doesn't exist (#176239) - Call shutdown_dispatcher when auditd stops - Add new logging function audit_log_semanage_message autorun-3.18-1.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 3.18-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes avahi-0.6.6-2 ------------- * Tue Feb 07 2006 Jason Vas Dias - 0.6.6-2 - rebuild for new gcc, glibc, glibc-kernheaders bind-30:9.3.2-4 --------------- * Tue Feb 07 2006 Jason Vas Dias - 30:9.3.2-4 - regenerate redhat_doc patch for non-DBUS builds - allow dbus builds to work with dbus version < 0.6 (bz #179816) cdparanoia-alpha9.8-27 ---------------------- * Wed Feb 08 2006 Monty Montgomery - alpha9.8-27 - rebuilt ckermit-8.0.211-4.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 8.0.211-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes control-center-1:2.13.91-1 -------------------------- * Wed Feb 08 2006 Matthias Clasen - 2.13.91-1 - Update to 2.13.91 - Reenable Spanish help cpio-2.6-11.2 ------------- * Tue Feb 07 2006 Jesse Keating - 2.6-11.2 - rebuilt for new gcc4.1 snapshot and glibc changes cpufreq-utils-1:0.4-1.1.22 -------------------------- * Thu Feb 09 2006 Dave Jones - rebuild. cpuspeed-1:1.2.1-1.29 --------------------- * Thu Feb 09 2006 Dave Jones - rebuild. cracklib-2.8.6-1.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 2.8.6-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes crash-4.0-2.18.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 4.0-2.18.1 - rebuilt for new gcc4.1 snapshot and glibc changes crypto-utils-2.2-9.2 -------------------- * Tue Feb 07 2006 Jesse Keating - 2.2-9.2 - rebuilt for new gcc4.1 snapshot and glibc changes cryptsetup-luks-1.0.1-4.2 ------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes cscope-15.5-13.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 15.5-13.1 - rebuilt for new gcc4.1 snapshot and glibc changes ctags-5.5.4-4.2 --------------- * Tue Feb 07 2006 Jesse Keating - 5.5.4-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes cups-1:1.1.23-30.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 1:1.1.23-30.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Wed Jan 25 2006 Tim Waugh - Fixed link patch. curl-7.15.1-1.2 --------------- * Tue Feb 07 2006 Jesse Keating - 7.15.1-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes cvs-1.11.21-3.1 --------------- * Tue Feb 07 2006 Jesse Keating - 1.11.21-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes cyrus-sasl-2.1.21-9.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 2.1.21-9.1 - rebuilt for new gcc4.1 snapshot and glibc changes dasher-3.99.2-2.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 3.99.2-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes db4-4.3.29-1.2 -------------- * Tue Feb 07 2006 Jesse Keating - 4.3.29-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes dcraw-0.0.20051211-1.1 ---------------------- * Tue Feb 07 2006 Jesse Keating - 0.0.20051211-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes desktop-file-utils-0.10-4.1 --------------------------- * Tue Feb 07 2006 Jesse Keating - 0.10-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes desktop-printing-0.19-5.1 ------------------------- * Tue Feb 07 2006 Jesse Keating - 0.19-5.1 - rebuilt for new gcc4.1 snapshot and glibc changes device-mapper-1.02.02-3.1 ------------------------- * Tue Feb 07 2006 Jesse Keating - 1.02.02-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes device-mapper-multipath-0.4.5-9.1.1 ----------------------------------- * Tue Feb 07 2006 Jesse Keating - 0.4.5-9.1.1 - rebuilt for new gcc4.1 snapshot and glibc changes dhcdbd-1.12-1.FC5.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 1.12-1.FC5.1 - rebuilt for new gcc4.1 snapshot and glibc changes dhcpv6-0.10-16 -------------- * Tue Feb 07 2006 Jason Vas Dias - 0.10-16 - rebuild for new gcc, glibc, glibc-kernheaders dialog-1.0.20051107-1.2 ----------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.20051107-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes dictd-1.9.15-5.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 1.9.15-5.1 - rebuilt for new gcc4.1 snapshot and glibc changes diffstat-1.41-1.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 1.41-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes diffutils-2.8.1-15.2 -------------------- * Tue Feb 07 2006 Jesse Keating - 2.8.1-15.2 - rebuilt for new gcc4.1 snapshot and glibc changes distcache-1.4.5-12.2 -------------------- * Tue Feb 07 2006 Jesse Keating - 1.4.5-12.2 - rebuilt for new gcc4.1 snapshot and glibc changes dmidecode-1:2.7-1.23 -------------------- * Thu Feb 09 2006 Dave Jones - rebuild. dmraid-1.0.0.rc9-FC5_5.1 ------------------------ * Tue Feb 07 2006 Jesse Keating - 1.0.0.rc9-FC5_5.1 - rebuilt for new gcc4.1 snapshot and glibc changes dos2unix-3.1-24.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 3.1-24.2 - rebuilt for new gcc4.1 snapshot and glibc changes dosfstools-2.11-4.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 2.11-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes dovecot-1.0-0.beta2.3.1 ----------------------- * Tue Feb 07 2006 Jesse Keating - 1.0-0.beta2.3.1 - rebuilt for new gcc4.1 snapshot and glibc changes doxygen-1:1.4.6-1.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 1:1.4.6-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes dtach-0.7-1.2 ------------- * Tue Feb 07 2006 Jesse Keating - 0.7-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes dump-0.4b41-1.1 --------------- * Tue Feb 07 2006 Jesse Keating - 0.4b41-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes dvd+rw-tools-5.21.4.10.8-6.2 ---------------------------- * Tue Feb 07 2006 Jesse Keating - 5.21.4.10.8-6.2 - rebuilt for new gcc4.1 snapshot and glibc changes dvgrab-2.0-1.2 -------------- * Tue Feb 07 2006 Jesse Keating - 2.0-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes e2fsprogs-1.38-6.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 1.38-6.1 - rebuilt for new gcc4.1 snapshot and glibc changes ed-0.2-38.2 ----------- * Tue Feb 07 2006 Jesse Keating - 0.2-38.2 - rebuilt for new gcc4.1 snapshot and glibc changes eel2-2.13.90-1.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 2.13.90-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes efax-0.9-27.1 ------------- * Tue Feb 07 2006 Jesse Keating - 0.9-27.1 - rebuilt for new gcc4.1 snapshot and glibc changes eject-2.1.2-1.2 --------------- * Tue Feb 07 2006 Jesse Keating - 2.1.2-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes elfutils-0.119-1.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 0.119-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes elilo-3.6-1.1 ------------- * Tue Feb 07 2006 Jesse Keating - 3.6-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes elinks-0.11.0-2.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 0.11.0-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes emacs-21.4-12.1 --------------- * Tue Feb 07 2006 Jesse Keating - 21.4-12.1 - rebuilt for new gcc4.1 snapshot and glibc changes enscript-1.6.4-1.1.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 1.6.4-1.1.1 - rebuilt for new gcc4.1 snapshot and glibc changes eog-2.13.90-1.1 --------------- * Tue Feb 07 2006 Jesse Keating - 2.13.90-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes epic-4:2.2-2.2 -------------- * Tue Feb 07 2006 Jesse Keating - 4:2.2-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes epiphany-1.9.6-2.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 1.9.6-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes eruby-1.0.5-5.2 --------------- * Tue Feb 07 2006 Jesse Keating - 1.0.5-5.2 - rebuilt for new gcc4.1 snapshot and glibc changes esound-1:0.2.36-2.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 1:0.2.36-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes ethereal-0.10.14-3.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 0.10.14-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes ethtool-3-1.2 ------------- * Tue Feb 07 2006 Jesse Keating - 3-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes evince-0.5.0-3.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 0.5.0-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes evolution-2.5.90-1.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 2.5.90-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Mon Jan 30 2006 David Malcolm - 2.5.90-1 - 2.5.90 - trimmed patches 805 and 808, as parts of these got merged upstream - trimmed and regenerated patch 806 to track upstream - removed the mail-to-task plugin XML UI file * Sat Jan 28 2006 David Malcolm - 2.5.5.1-2 - added missing patch evolution-connector-2.5.9.0-2.1 ------------------------------- * Tue Feb 07 2006 Jesse Keating - 2.5.9.0-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes evolution-data-server-1.5.90-2.1 -------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.5.90-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes evolution-sharp-0.10.2-7.1 -------------------------- * Tue Feb 07 2006 Jesse Keating - 0.10.2-7.1 - rebuilt for new gcc4.1 snapshot and glibc changes evolution-webcal-2.4.1-3.1 -------------------------- * Tue Feb 07 2006 Jesse Keating - 2.4.1-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes expat-1.95.8-8.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 1.95.8-8.1 - rebuilt for new gcc4.1 snapshot and glibc changes f-spot-0.1.8-2.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 0.1.8-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes fbset-2.1-20.2 -------------- * Tue Feb 07 2006 Jesse Keating - 2.1-20.2 - rebuilt for new gcc4.1 snapshot and glibc changes fence-1.32.10-0.FC5.1.1 ----------------------- * Tue Feb 07 2006 Jesse Keating - 1.32.10-0.FC5.1.1 - rebuilt for new gcc4.1 snapshot and glibc changes festival-1.95-5.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 1.95-5.1 - rebuilt for new gcc4.1 snapshot and glibc changes fetchmail-6.3.2.1-1.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 6.3.2.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes file-4.16-6.1 ------------- * Tue Feb 07 2006 Jesse Keating - 4.16-6.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Sat Feb 04 2006 Radek Vok??l 4.16-6 - xen patch, recognizes Xen saved domain * Fri Jan 13 2006 Radek Vokal 4.16-5 - fix for 64bit arrays file-roller-2.13.90-1.1 ----------------------- * Tue Feb 07 2006 Jesse Keating - 2.13.90-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes filesystem-2.3.7-1.2 -------------------- * Tue Feb 07 2006 Jesse Keating - 2.3.7-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes findutils-1:4.2.27-3.1 ---------------------- * Tue Feb 07 2006 Jesse Keating - 1:4.2.27-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes finger-0.17-32.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 0.17-32.1 - rebuilt for new gcc4.1 snapshot and glibc changes firefox-1.5.0.1-2.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 1.5.0.1-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes firstboot-1.4.4-1 ----------------- * Wed Feb 08 2006 Chris Lumens 1.4.4-1 - Get rid of chkconfig --off calls. - Smarter checking for if we need to reboot or not. flac-1.1.2-25.2 --------------- * Tue Feb 07 2006 Jesse Keating - 1.1.2-25.2 - rebuilt for new gcc4.1 snapshot and glibc changes flex-2.5.4a-37.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 2.5.4a-37.1 - rebuilt for new gcc4.1 snapshot and glibc changes fontconfig-2.3.93.cvs20060208-1 ------------------------------- * Wed Feb 08 2006 Matthias Clasen - 2.3.93.cvs20060208-1 - Newer cvs snapshot foomatic-3.0.2-33.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 3.0.2-33.1 - rebuilt for new gcc4.1 snapshot and glibc changes freeglut-2.4.0-3.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 2.4.0-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes freeradius-1.0.5-1.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes freetype-2.1.10-5.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 2.1.10-5.2 - rebuilt for new gcc4.1 snapshot and glibc changes fribidi-0.10.4-8.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 0.10.4-8.2 - rebuilt for new gcc4.1 snapshot and glibc changes frysk-0.0.1.2006.01.22-0.FC5.1.1 -------------------------------- * Tue Feb 07 2006 Jesse Keating - 0.0.1.2006.01.22-0.FC5.1.1 - rebuilt for new gcc4.1 snapshot and glibc changes ftp-0.17-32.1.1 --------------- * Tue Feb 07 2006 Jesse Keating - 0.17-32.1.1 - rebuilt for new gcc4.1 snapshot and glibc changes g-wrap-1.3.4-9.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 1.3.4-9.2 - rebuilt for new gcc4.1 snapshot and glibc changes gail-1.8.8-3 ------------ * Wed Feb 08 2006 Matthias Clasen - 1.8.8-3 - Avoid crashing the gimp - Use api docs from tarball * Tue Feb 07 2006 Jesse Keating - 1.8.8-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes gaim-1:1.5.0-15.fc5 ------------------- * Tue Feb 07 2006 Warren Togami 1:1.5.0-15 - allow compat with gaim-2.x log format (rlaager) * Sat Jan 28 2006 David Malcolm 1:1.5.0-14 - rebuild for new e-d-s * Fri Jan 13 2006 Warren Togami 1:1.5.0-13 - buildreq desktop-file-utils (ivazquez #176688) - detect NSS in a generic way and abort on failure gal-1:0.24-6.2 -------------- * Tue Feb 07 2006 Jesse Keating - 1:0.24-6.2 - rebuilt for new gcc4.1 snapshot and glibc changes gamin-0.1.7-1.2 --------------- * Tue Feb 07 2006 Jesse Keating - 0.1.7-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes gawk-3.1.5-5.1 -------------- * Tue Feb 07 2006 Jesse Keating - 3.1.5-5.1 - rebuilt for new gcc4.1 snapshot and glibc changes gconf-editor-2.13.90-1.1 ------------------------ * Tue Feb 07 2006 Jesse Keating - 2.13.90-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes gd-2.0.33-6.1 ------------- * Tue Feb 07 2006 Jesse Keating - 2.0.33-6.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Jan 20 2006 Phil Knirsch 2.0.33-6 - Included a few more overflow checks (#177907) gdb-6.3.0.0-1.98.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 6.3.0.0-1.98.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Mon Jan 16 2006 Alexandre Oliva 6.3.0.0-1.98 - Bump up release number. * Mon Dec 19 2005 Alexandre Oliva 6.3.0.0-1.94 - Fix type-punning warnings issued by GCC 4.1. gdbm-1.8.0-26.1 --------------- * Tue Feb 07 2006 Jesse Keating - 1.8.0-26.1 - rebuilt for new gcc4.1 snapshot and glibc changes gdk-pixbuf-1:0.22.0-21.2 ------------------------ * Tue Feb 07 2006 Jesse Keating - 1:0.22.0-21.2 - rebuilt for new gcc4.1 snapshot and glibc changes gdm-1:2.13.0.7-1.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 1:2.13.0.7-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes gecko-sharp2-0.11-4.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 0.11-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes genromfs-0.5.1-3.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 0.5.1-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes geronimo-specs-0:1.0-0.M2.2jpp_6fc ---------------------------------- * Tue Feb 07 2006 Jesse Keating - 0:1.0-0.M2.2jpp_6fc - rebuilt for new gcc4.1 snapshot and glibc changes gettext-0.14.5-2.2.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 0.14.5-2.2.1 - rebuilt for new gcc4.1 snapshot and glibc changes gftp-1:2.0.18-3.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 1:2.0.18-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes ghostscript-8.15.1-5.1 ---------------------- * Tue Feb 07 2006 Jesse Keating - 8.15.1-5.1 - rebuilt for new gcc4.1 snapshot and glibc changes giflib-4.1.3-6.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 4.1.3-6.2 - rebuilt for new gcc4.1 snapshot and glibc changes gimp-2:2.2.10-2.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 2:2.2.10-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Tue Jan 10 2006 Nils Philippsen - rebuild with lcms * Thu Dec 29 2005 Nils Philippsen - 2.2.10 - version 2.2.10 gimp-print-4.2.7-15.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 4.2.7-15.1 - rebuilt for new gcc4.1 snapshot and glibc changes gkrellm-2.2.7-5.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 2.2.7-5.2 - rebuilt for new gcc4.1 snapshot and glibc changes glade2-2.12.1-1.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 2.12.1-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes glib-1:1.2.10-18.2.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 1:1.2.10-18.2.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Tue Jan 03 2006 Jesse Keating 1:1.2.10-18.2 - rebuilt again * Fri Dec 09 2005 Jesse Keating - rebuilt glib-java-0.2.3-1.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 0.2.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Mon Jan 30 2006 Adam Jocksch - bumped version to 0.2.3, updated tarball. * Thu Dec 22 2005 Adam Jocksch - bumped version to 0.2.2, updated tarball. glib2-2.9.5-1.1 --------------- * Tue Feb 07 2006 Jesse Keating - 2.9.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes glibc-kernheaders-3.0-5.1 ------------------------- * Tue Feb 07 2006 Jesse Keating - 3.0-5.1 - rebuilt for new gcc4.1 snapshot and glibc changes gmime-2.1.19-2.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 2.1.19-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes gmp-4.1.4-6.2 ------------- * Tue Feb 07 2006 Jesse Keating - 4.1.4-6.2 - rebuilt for new gcc4.1 snapshot and glibc changes gnbd-1.0.2-0.2.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 1.0.2-0.2.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 16 2005 Chris Feist - Rebuilt w/ new upstream sources * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-applet-vm-0.0.5-1.1 ------------------------- * Tue Feb 07 2006 Jesse Keating - 0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-applets-1:2.13.3-4.1 -------------------------- * Tue Feb 07 2006 Jesse Keating - 1:2.13.3-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Wed Feb 01 2006 Matthias Clasen 2.13.3-4 - Fix an overflow in the weather applet gnome-bluetooth-0.6.0-2.2 ------------------------- * Tue Feb 07 2006 Jesse Keating - 0.6.0-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-desktop-2.13.90-1.1 ------------------------- * Tue Feb 07 2006 Jesse Keating - 2.13.90-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-games-1:2.13.6-3.1 ------------------------ * Tue Feb 07 2006 Jesse Keating - 1:2.13.6-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-kerberos-0.3.3-2.2 ------------------------ * Tue Feb 07 2006 Jesse Keating - 0.3.3-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-keyring-0.4.6-1.2 ----------------------- * Tue Feb 07 2006 Jesse Keating - 0.4.6-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-keyring-manager-2.12.0-2.2 -------------------------------- * Tue Feb 07 2006 Jesse Keating - 2.12.0-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-libs-1:1.4.1.2.90-48.1 ---------------------------- * Tue Feb 07 2006 Jesse Keating - 1:1.4.1.2.90-48.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-media-2.13.91-2.1 ----------------------- * Tue Feb 07 2006 Jesse Keating - 2.13.91-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-menus-2.13.5-5.1 ---------------------- * Tue Feb 07 2006 Jesse Keating - 2.13.5-5.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-mime-data-2.4.2-1.2 ------------------------- * Tue Feb 07 2006 Jesse Keating - 2.4.2-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-netstatus-2.12.0-3.2 -------------------------- * Tue Feb 07 2006 Jesse Keating - 2.12.0-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-nettool-2.13.90-1.1 ------------------------- * Tue Feb 07 2006 Jesse Keating - 2.13.90-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-panel-2.13.90-1.1 ----------------------- * Tue Feb 07 2006 Jesse Keating - 2.13.90-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-pilot-2.0.13-7.fc5.2 -------------------------- * Tue Feb 07 2006 Jesse Keating - 2.0.13-7.fc5.2 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-pilot-conduits-2.0.13-3.FC5.1 ----------------------------------- * Tue Feb 07 2006 Jesse Keating - 2.0.13-3.FC5.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-print-1:0.37-12.2 ----------------------- * Tue Feb 07 2006 Jesse Keating - 1:0.37-12.2 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-python2-2.12.3-1.1 ------------------------ * Tue Feb 07 2006 Jesse Keating - 2.12.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-python2-extras-2.13.3-3.1 ------------------------------- * Tue Feb 07 2006 Jesse Keating - 2.13.3-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-screensaver-2.13.90-2.1 ----------------------------- * Tue Feb 07 2006 Jesse Keating - 2.13.90-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-session-2.13.90-1.1 ------------------------- * Tue Feb 07 2006 Jesse Keating - 2.13.90-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-speech-0.3.9-1.2 ---------------------- * Tue Feb 07 2006 Jesse Keating - 0.3.9-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-spell-1.0.5-13.1 ---------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.5-13.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-system-monitor-2.13.90-1.1 -------------------------------- * Tue Feb 07 2006 Jesse Keating - 2.13.90-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-terminal-2.13.90-2 ------------------------ * Thu Feb 09 2006 Matthias Clasen - 2.13.90-2 - Re-add "Open Link" menuitems * Tue Feb 07 2006 Jesse Keating - 2.13.90-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-user-share-0.9-2.1 ------------------------ * Tue Feb 07 2006 Jesse Keating - 0.9-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-utils-1:2.13.91-2.1 ------------------------- * Tue Feb 07 2006 Jesse Keating - 1:2.13.91-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-vfs2-2.13.4-7.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 2.13.4-7.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-volume-manager-1.5.11-1.1 ------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.5.11-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnopernicus-1.0.1-1.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnu-efi-3.0a-7.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 3.0a-7.2 - rebuilt for new gcc4.1 snapshot and glibc changes gnucash-1.8.12-2.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 1.8.12-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnupg-1.4.2-3.2 --------------- * Tue Feb 07 2006 Jesse Keating - 1.4.2-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes gnuplot-4.0.0-10.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 4.0.0-10.2 - rebuilt for new gcc4.1 snapshot and glibc changes gnutls-1.2.9-3.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 1.2.9-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes gob2-2.0.12-1.2 --------------- * Tue Feb 07 2006 Jesse Keating - 2.0.12-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes gok-1.0.5-6.2 ------------- * Tue Feb 07 2006 Jesse Keating - 1.0.5-6.2 - rebuilt for new gcc4.1 snapshot and glibc changes gpart-0.1h-1.2 -------------- gperf-3.0.1-7.2 --------------- * Tue Feb 07 2006 Jesse Keating - 3.0.1-7.2 - rebuilt for new gcc4.1 snapshot and glibc changes gphoto2-2.1.99-5.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 2.1.99-5.1 - rebuilt for new gcc4.1 snapshot and glibc changes gpm-1.20.1-73.1 --------------- * Tue Feb 07 2006 Jesse Keating - 1.20.1-73.1 - rebuilt for new gcc4.1 snapshot and glibc changes grep-2.5.1-52.1 --------------- * Tue Feb 07 2006 Jesse Keating - 2.5.1-52.1 - rebuilt for new gcc4.1 snapshot and glibc changes groff-1.18.1.1-9.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 1.18.1.1-9.1 - rebuilt for new gcc4.1 snapshot and glibc changes grub-0.97-2.1 ------------- * Tue Feb 07 2006 Jesse Keating - 0.97-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes gsf-sharp-0.6-6.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 0.6-6.1 - rebuilt for new gcc4.1 snapshot and glibc changes gsl-1.7-1.2 ----------- * Tue Feb 07 2006 Jesse Keating - 1.7-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes gstreamer-0.10.2-1.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 0.10.2-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Wed Jan 18 2006 John (J5) Palmieri - 0.10.2-1 - Upgrade to 0.10.2 * Fri Jan 06 2006 John (J5) Palmieri - 0.10.1-1 - New upstream version gstreamer-plugins-base-0.10.2-2.1 --------------------------------- * Tue Feb 07 2006 Jesse Keating - 0.10.2-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes gstreamer-plugins-good-0.10.1-1.1 --------------------------------- * Tue Feb 07 2006 Jesse Keating - 0.10.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes gstreamer08-plugins-0.8.11-6.1 ------------------------------ * Tue Feb 07 2006 Jesse Keating - 0.8.11-6.1 - rebuilt for new gcc4.1 snapshot and glibc changes gthumb-2.7.2-2.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 2.7.2-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Jan 27 2006 Ray Strode - 2.7.2-2 - drop redhat-menus buildrequires - use make install DESTDIR instead %makeinstall gtk+-1:1.2.10-49.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 1:1.2.10-49.2 - rebuilt for new gcc4.1 snapshot and glibc changes gtk-engines-1:0.12-7.2 ---------------------- * Tue Feb 07 2006 Jesse Keating - 1:0.12-7.2 - rebuilt for new gcc4.1 snapshot and glibc changes gtk-sharp-1.0.10-4.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.10-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes gtk-sharp2-2.8.0-1.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 2.8.0-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes gtk2-2.8.11-7 ------------- * Thu Feb 09 2006 Matthias Clasen 2.8.11-7 - Fix a double free in the file chooser * Tue Feb 07 2006 Christopher Aillon 2.8.11-6 - Fix up jkeating's recent %changelog entry to match this spec's style - Make the devel package Require %{version}-%{release} * Tue Feb 07 2006 Jesse Keating 2.8.11-5.1 - rebuilt for new gcc4.1 snapshot and glibc changes gtk2-engines-2.7.4-1.1 ---------------------- * Tue Feb 07 2006 Jesse Keating - 2.7.4-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes gtkhtml-1.1.9-11.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 1.1.9-11.2 - rebuilt for new gcc4.1 snapshot and glibc changes gtkhtml2-2.6.3-1.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 2.6.3-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes gtkhtml3-3.9.90-3.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 3.9.90-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes gtksourceview-1.5.7-2.1 ----------------------- * Tue Feb 07 2006 Jesse Keating - 1.5.7-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Sat Feb 04 2006 Matthias Clasen - Update URL gtkspell-2.0.11-1.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 2.0.11-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes guile-5:1.6.7-5.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 5:1.6.7-5.1 - rebuilt for new gcc4.1 snapshot and glibc changes gulm-1.0.5-0.FC5.1.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.5-0.FC5.1.1 - rebuilt for new gcc4.1 snapshot and glibc changes gwenhywfar-1.99.2-1.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 1.99.2-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes gzip-1.3.5-6.2 -------------- * Tue Feb 07 2006 Jesse Keating - 1.3.5-6.2 - rebuilt for new gcc4.1 snapshot and glibc changes h2ps-2.06-14.2 -------------- * Tue Feb 07 2006 Jesse Keating - 2.06-14.2 - rebuilt for new gcc4.1 snapshot and glibc changes hal-0.5.6-3.1 ------------- * Tue Feb 07 2006 Jesse Keating - 0.5.6-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Wed Jan 18 2006 John (J5) Palmieri - 0.5.6-3 - Patch storage-method policy so that the eject method is available to audio cd's hal-cups-utils-0.5.5-1.1 ------------------------ * Tue Feb 07 2006 Jesse Keating - 0.5.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes hardlink-1:1.0-1.20.1 --------------------- * Tue Feb 07 2006 Jesse Keating - error: line 4: Tag takes single token only: Release: :.1 1.19.1 - rebuilt for new gcc4.1 snapshot and glibc changes hdparm-6.3-2.1 -------------- * Tue Feb 07 2006 Jesse Keating - 6.3-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes hesiod-3.0.2-31.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 3.0.2-31.2 - rebuilt for new gcc4.1 snapshot and glibc changes hexedit-1.2.12-3.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 1.2.12-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes hfsutils-3.2.6-7.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 3.2.6-7.2 - rebuilt for new gcc4.1 snapshot and glibc changes hsqldb-0:1.80.1-1jpp_6fc ------------------------ * Tue Feb 07 2006 Jesse Keating - 0:1.80.1-1jpp_6fc - rebuilt for new gcc4.1 snapshot and glibc changes httpd-2.2.0-5.1.1 ----------------- * Tue Feb 07 2006 Jesse Keating - (none):2.2.0-5.1.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Mon Feb 06 2006 Joe Orton 2.2.0-5.1 - mod_auth_basic/mod_authn_file: if no provider is configured, and AuthUserFile is not configured, decline to handle authn silently rather than failing noisily. From buildsys at redhat.com Thu Feb 9 15:08:02 2006 From: buildsys at redhat.com (Build System) Date: Thu, 9 Feb 2006 10:08:02 -0500 Subject: rawhide report: 20060209 changes (part 2/2) Message-ID: <200602091508.k19F8254012390@porkchop.devel.redhat.com> icon-slicer-0.3-7.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 0.3-7.2 - rebuilt for new gcc4.1 snapshot and glibc changes icu-3.4-6.1 ----------- * Tue Feb 07 2006 Jesse Keating - 3.4-6.1 - rebuilt for new gcc4.1 snapshot and glibc changes iddev-2.0.0-4.FC5.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 2.0.0-4.FC5.2 - rebuilt for new gcc4.1 snapshot and glibc changes imake-1.0.1-1.1 --------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes imlib-1:1.9.13-26.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 1:1.9.13-26.2 - rebuilt for new gcc4.1 snapshot and glibc changes indent-2.2.9-12.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 2.2.9-12.1 - rebuilt for new gcc4.1 snapshot and glibc changes inn-2.4.2-4.2 ------------- * Tue Feb 07 2006 Jesse Keating - 2.4.2-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes iproute-2.6.15-1.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 2.6.15-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes iprutils-2.1.1-1.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 2.1.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes iptables-1.3.5-1.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 1.3.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes iptraf-3.0.0-1.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 3.0.0-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes iptstate-1.4-1.1.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 1.4-1.1.2 - rebuilt for new gcc4.1 snapshot and glibc changes iputils-20020927-34.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 20020927-34.1 - rebuilt for new gcc4.1 snapshot and glibc changes ipv6calc-0.50-1.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 0.50-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes ipvsadm-1.24-7.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 1.24-7.2 - rebuilt for new gcc4.1 snapshot and glibc changes irda-utils-0.9.16-7.2 --------------------- * Tue Feb 07 2006 Jesse Keating - 0.9.16-7.2 - rebuilt for new gcc4.1 snapshot and glibc changes irqbalance-1:1.12-1.23 ---------------------- * Thu Feb 09 2006 Dave Jones - rebuild. isdn4k-utils-3.2-38.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 3.2-38.1 - rebuilt for new gcc4.1 snapshot and glibc changes isicom-3.05-18.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 3.05-18.2 - rebuilt for new gcc4.1 snapshot and glibc changes java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_78rh ------------------------------------------ * Wed Feb 08 2006 Thomas Fitzsimmons - 0:1.4.2.0-40jpp_78rh - Install javadocs in versioned directory. * Tue Feb 07 2006 Jesse Keating - 0:1.4.2.0-40jpp_77rh - rebuilt for new gcc4.1 snapshot and glibc changes java_cup-1:0.10-0.k.1jpp_7fc ---------------------------- * Tue Feb 07 2006 Jesse Keating - 1:0.10-0.k.1jpp_7fc - rebuilt for new gcc4.1 snapshot and glibc changes javacc-0:3.2-1jpp_5fc --------------------- * Tue Feb 07 2006 Jesse Keating - 0:3.2-1jpp_5fc - rebuilt for new gcc4.1 snapshot and glibc changes jfsutils-1.1.10-3.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 1.1.10-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes joe-3.3-1.2 ----------- * Tue Feb 07 2006 Jesse Keating - 3.3-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes joystick-1.2.15-20.2 -------------------- * Tue Feb 07 2006 Jesse Keating - 1.2.15-20.2 - rebuilt for new gcc4.1 snapshot and glibc changes jpilot-0.99.8-2.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 0.99.8-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes jsch-0:0.1.18-1jpp_5fc ---------------------- * Tue Feb 07 2006 Jesse Keating - 0:0.1.18-1jpp_5fc - rebuilt for new gcc4.1 snapshot and glibc changes jwhois-3.2.3-3.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 3.2.3-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes k3b-0:0.12.10-2.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 0:0.12.10-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes kasumi-1.0-1.fc5.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 1.0-1.fc5.1 - rebuilt for new gcc4.1 snapshot and glibc changes kbd-1.12-13.1 ------------- * Tue Feb 07 2006 Jesse Keating - 1.12-13.1 - rebuilt for new gcc4.1 snapshot and glibc changes kcc-2.3-24.2 ------------ * Tue Feb 07 2006 Jesse Keating - 2.3-24.2 - rebuilt for new gcc4.1 snapshot and glibc changes kdbg-1:2.0.2-1.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 1:2.0.2-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes kdeaccessibility-1:3.5.1-1.1 ---------------------------- * Tue Feb 07 2006 Jesse Keating - 1:3.5.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes kdeaddons-3.5.1-1.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 3.5.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes kdeadmin-7:3.5.1-1.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 7:3.5.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes kdeartwork-3.5.1-1.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 3.5.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes kdebase-6:3.5.1-2.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 6:3.5.1-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes kdebindings-3.5.1-1.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 3.5.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes kdeedu-3.5.1-1.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 3.5.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes kdegames-6:3.5.1-1.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 6:3.5.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes kdelibs-6:3.5.1-2.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 6:3.5.1-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes kdemultimedia-6:3.5.1-1.1 ------------------------- * Tue Feb 07 2006 Jesse Keating - 6:3.5.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes kdenetwork-7:3.5.1-1.1 ---------------------- * Tue Feb 07 2006 Jesse Keating - 7:3.5.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes kdepim-6:3.5.1-1.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 6:3.5.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes kdesdk-3.5.1-1.1 ---------------- * Tue Feb 07 2006 Jesse Keating - (none):3.5.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes kdeutils-6:3.5.1-1.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 6:3.5.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes kdewebdev-6:3.5.1-1.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 6:3.5.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes kernel-2.6.15-1.1917_FC5 ------------------------ kernel-xen-2.6.15-1.51_FC5 -------------------------- * Wed Feb 08 2006 Jeremy Katz - update to newer hypervisor snapshot, conflict with older tools - fix pae hypervisor new-kernel-pkg call * Wed Feb 08 2006 Juan Quintela - make_target & kernel_image passed as arguments to BuildKernel. * Wed Feb 08 2006 Juan Quintela - removed SMP_ALTERNATIVES from smp kernel. kexec-tools-1.101-7.1.1 ----------------------- * Tue Feb 07 2006 Jesse Keating - 1.101-7.1.1 - rebuilt for new gcc4.1 snapshot and glibc changes kon2-0.3.9b-26.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 0.3.9b-26.2 - rebuilt for new gcc4.1 snapshot and glibc changes krb5-auth-dialog-0.6-1.1 ------------------------ * Tue Feb 07 2006 Jesse Keating - 0.6-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes krbafs-1.2.2-9.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 1.2.2-9.2 - rebuilt for new gcc4.1 snapshot and glibc changes kudzu-1.2.25-1 -------------- * Tue Feb 07 2006 Bill Nottingham - 1.2.25-1 - in installer environment, sg isn't loaded, so there are deviceless scsi devs (#180378) lam-2:7.1.1-8.FC5.2 ------------------- * Tue Feb 07 2006 Jason Vas Dias - 2:7.1.1-8.2 - rebuild for new gcc, glibc, glibc-kernheaders lcms-1.15-1.1 ------------- * Tue Feb 07 2006 Jesse Keating - 1.15-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes less-394-2.1 ------------ * Tue Feb 07 2006 Jesse Keating - 394-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes lftp-3.4.2-1 ------------ * Wed Feb 08 2006 Jason Vas Dias - 3.4.2-1 - Upgrade to upstream version 3.4.2, that fixes 3.4.1's coredump * Tue Feb 07 2006 Jason Vas Dias - 3.4.1-1 - Upgrade to upstream version 3.4.1 - fix core dump lha-1.14i-19.2 -------------- * Tue Feb 07 2006 Jesse Keating - 1.14i-19.2 - rebuilt for new gcc4.1 snapshot and glibc changes libFS-1.0.0-2.1 --------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libICE-1.0.0-2.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libIDL-0.8.6-2.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 0.8.6-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes libSM-1.0.0-2.1 --------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libX11-1.0.0-2.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXau-1.0.0-2.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXaw-1.0.1-1.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXcomposite-0.2.2.2-2.1 ------------------------- * Tue Feb 07 2006 Jesse Keating - 0.2.2.2-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXdamage-1.0.2.2-2.1 ---------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.2.2-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXdmcp-1.0.0-2.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 1.0.0-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXext-1.0.0-3.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXfixes-3.0.1.2-2.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 3.0.1.2-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libaio-0.3.106-2.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 0.3.106-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libao-0.8.6-1.2 --------------- * Tue Feb 07 2006 Jesse Keating - 0.8.6-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes libart_lgpl-2.3.17-2.2 ---------------------- * Tue Feb 07 2006 Jesse Keating - 2.3.17-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes libavc1394-0.5.1-2.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 0.5.1-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libbonobo-2.13.1-8.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 2.13.1-8.1 - rebuilt for new gcc4.1 snapshot and glibc changes libbonoboui-2.13.1-4.1 ---------------------- * Tue Feb 07 2006 Jesse Keating - 2.13.1-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes libc-client-2004g-2.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 2004g-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libcap-1.10-24.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 1.10-24.1 - rebuilt for new gcc4.1 snapshot and glibc changes libchewing-0.2.7-1.2 -------------------- * Tue Feb 07 2006 Jesse Keating - 0.2.7-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes libcroco-0.6.0-6.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 0.6.0-6.2 - rebuilt for new gcc4.1 snapshot and glibc changes libdaemon-0.10-3 ---------------- * Tue Feb 07 2006 Jason Vas Dias - 0.10-3 - rebuild for new gcc, glibc, glibc-kernheaders libdbi-0.8.1-1.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 0.8.1-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes libdbi-drivers-0.8.1a-1.2 ------------------------- * Tue Feb 07 2006 Jesse Keating - 0.8.1a-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes libdmx-1.0.1-1.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes libdrm-2.0-2.1 -------------- * Tue Feb 07 2006 Jesse Keating - 2.0-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libevent-1.1a-3.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 1.1a-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes libexif-0.6.12-3.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 0.6.12-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes libfontenc-1.0.1-1.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes libgail-gnome-1.1.3-1.1 ----------------------- * Tue Feb 07 2006 Jesse Keating - 1.1.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes libgconf-java-2.12.1-2.1 ------------------------ * Tue Feb 07 2006 Jesse Keating - 2.12.1-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libgcrypt-1.2.2-1.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 1.2.2-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes libgdiplus-1.1.13.2-1.1 ----------------------- * Tue Feb 07 2006 Jesse Keating - 1.1.13.2-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes libghttp-1:1.0.9-11.2 --------------------- * Tue Feb 07 2006 Jesse Keating - 1:1.0.9-11.2 - rebuilt for new gcc4.1 snapshot and glibc changes libglade-1:0.17-16.2 -------------------- * Tue Feb 07 2006 Jesse Keating - 1:0.17-16.2 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 09 2005 Jesse Keating - rebuilt * Wed Mar 02 2005 Matthias Clasen 1:0.17-16 - Replace Copyright: with License: - rebuilt with gcc4 libglade-java-2.12.2-1.1 ------------------------ * Tue Feb 07 2006 Jesse Keating - 2.12.2-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Mon Jan 30 2006 Adam jocksch - 2.12.2-1 - Updated tarball, deps. * Wed Dec 21 2005 Jesse Keating - 2.12.1-3 - rebuilt again libglade2-2.5.1-3.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 2.5.1-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes libgnome-java-2.12.1-3.1 ------------------------ * Tue Feb 07 2006 Jesse Keating - 2.12.1-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes libgnomecanvas-2.13.0-1.1 ------------------------- * Tue Feb 07 2006 Jesse Keating - 2.13.0-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes libgnomecups-0.2.2-3.2 ---------------------- * Tue Feb 07 2006 Jesse Keating - 0.2.2-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes libgnomeprint22-2.12.1-4.1 -------------------------- * Tue Feb 07 2006 Jesse Keating - 2.12.1-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes libgnomeprintui22-2.12.1-1.2 ---------------------------- * Tue Feb 07 2006 Jesse Keating - 2.12.1-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes libgnomeui-2.13.3-1.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 2.13.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes libgpg-error-1.1-1.2 -------------------- * Tue Feb 07 2006 Jesse Keating - 1.1-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes libgpod-0.3.0-2.1 ----------------- libgsf-1.13.3-2.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 1.13.3-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes libgssapi-0.7-1.1 ----------------- libgtk-java-2.8.3-1.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 2.8.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Mon Jan 30 2006 Adam Jocksch - 2.8.3-1 - updated tarball to libgtk-java-2.8.3.tar.gz. * Thu Dec 22 2005 Andrw Cagney - 2.8.2-0 Adam Jocksch - import libgtk-java-2.8.2.tar.gz libgtop2-2.13.3-1.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 2.13.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes libibverbs-1.0.rc4-0.4265.1.FC5.2 --------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.rc4-0.4265.1.FC5.2 - rebuilt for new gcc4.1 snapshot and glibc changes libiec61883-1.0.0-10.fc5.1 -------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0-10.fc5.1 - rebuilt for new gcc4.1 snapshot and glibc changes libieee1284-0.2.9-3.2 --------------------- * Tue Feb 07 2006 Jesse Keating - 0.2.9-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes libjpeg-6b-36.2 --------------- * Tue Feb 07 2006 Jesse Keating - 6b-36.2 - rebuilt for new gcc4.1 snapshot and glibc changes liblbxutil-1.0.0-2.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libmng-1.0.9-3.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 1.0.9-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes libmthca-1.0.rc4-0.4265.1.FC5.2 ------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.rc4-0.4265.1.FC5.2 - rebuilt for new gcc4.1 snapshot and glibc changes libmusicbrainz-2.1.1-1.2 ------------------------ * Tue Feb 07 2006 Jesse Keating - 2.1.1-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes libnl-1.0-0.7.pre5.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 1.0-0.7.pre5.1 - rebuilt for new gcc4.1 snapshot and glibc changes libnotify-0.3.0-4.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 0.3.0-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes libofx-0.8.0-2.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 0.8.0-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libogg-2:1.1.3-1.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 2:1.1.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes liboil-0.3.6-3.fc5.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 0.3.6-3.fc5.1 - rebuilt for new gcc4.1 snapshot and glibc changes liboldX-1.0.1-1.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes libpfm-3.0-4.2 -------------- * Tue Feb 07 2006 Jesse Keating - 3.0-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes libpng-2:1.2.8-2.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 2:1.2.8-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes libpng10-1.0.18-3.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.18-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes libraw1394-1.2.0-3.fc5.1 ------------------------ * Tue Feb 07 2006 Jesse Keating - 1.2.0-3.fc5.1 - rebuilt for new gcc4.1 snapshot and glibc changes librtas-1.2.4-1.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 1.2.4-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes libsdp-0.90-0.4265.1.FC5.2 -------------------------- libsetrans-0.1.18-1.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 0.1.18-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes libsilc-0:0.9.12-12.2 --------------------- * Tue Feb 07 2006 Jesse Keating - 0:0.9.12-12.2 - rebuilt for new gcc4.1 snapshot and glibc changes libsoup-2.2.7-1.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 2.2.7-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes libtermcap-2.0.8-44.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 2.0.8-44.1 - rebuilt for new gcc4.1 snapshot and glibc changes libtheora-0:1.0alpha5-1.2 ------------------------- * Tue Feb 07 2006 Jesse Keating - 0:1.0alpha5-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes libtiff-3.7.4-3.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 3.7.4-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes libtool-1.5.22-2.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 1.5.22-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libunwind-0.98.2-3.2 -------------------- * Tue Feb 07 2006 Jesse Keating - 0.98.2-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes libusb-0.1.11-2.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 0.1.11-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libuser-0.54.3-1.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 0.54.3-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes libvir-0.0.2-1.1 ---------------- libvorbis-1:1.1.2-1.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 1:1.1.2-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes libvte-java-0.11.11-8.1 ----------------------- * Tue Feb 07 2006 Jesse Keating - 0.11.11-8.1 - rebuilt for new gcc4.1 snapshot and glibc changes libwmf-0.2.8.4-4.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 0.2.8.4-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes libwnck-2.13.90-1.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 2.13.90-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes libwpd-0.8.4-1.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 0.8.4-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 09 2005 Jesse Keating 0.8.4-1.1 - rebuilt * Fri Dec 02 2005 Caolan McNamara 0.8.4-1 - next version libwvstreams-4.2.1-1.1 ---------------------- * Tue Feb 07 2006 Jesse Keating - 4.2.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes lm_sensors-2.9.1-6.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 2.9.1-6.1 - rebuilt for new gcc4.1 snapshot and glibc changes magma-plugins-1.0.5-0.FC5.1.1 ----------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.5-0.FC5.1.1 - rebuilt for new gcc4.1 snapshot and glibc changes mcelog-1:0.6-1.16 ----------------- * Thu Feb 09 2006 Dave Jones - rebuild. * Wed Feb 08 2006 Dave Jones - Update to upstream 0.6 memtest86+-1.65-2.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 1.65-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes microcode_ctl-1:1.13-1.30 ------------------------- * Thu Feb 09 2006 Dave Jones - rebuild. mkbootdisk-1.5.2-5.2 -------------------- * Tue Feb 07 2006 Jesse Keating - 1.5.2-5.2 - rebuilt for new gcc4.1 snapshot and glibc changes netatalk-4:2.0.3-4.2 -------------------- * Tue Feb 07 2006 Jason Vas Dias - rebuild for new gcc, glibc, glibc-kernheaders openCryptoki-2.1.6-2.2 ---------------------- * Tue Feb 07 2006 Jesse Keating - 2.1.6-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes patchutils-0.2.31-2.2 --------------------- * Tue Feb 07 2006 Jesse Keating - 0.2.31-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes perl-Date-Calc-5.4-1.2.1 ------------------------ * Tue Feb 07 2006 Jesse Keating - 5.4-1.2.1 - rebuilt for new gcc4.1 snapshot and glibc changes pvm-3.4.5-6.7 ------------- * Tue Feb 07 2006 Jason Vas Dias - 3.4.5-6.7 - rebuild for new gcc, glibc, glibc-kernheaders radvd-0.9.1-1.1 --------------- * Tue Feb 07 2006 Jason Vas Dias - 0.9.1-1.1 - rebuild for new gcc, glibc, glibc-kernheaders redhat-menus-6.6.5-1 -------------------- * Thu Feb 09 2006 Matthias Clasen - 6.6.5-1 - Really move pirut to toplevel rgmanager-1.9.44-0.FC5.1.1 -------------------------- * Tue Feb 07 2006 Jesse Keating - 1.9.44-0.FC5.1.1 - rebuilt for new gcc4.1 snapshot and glibc changes rhpxl-0.14-1 ------------ * Wed Feb 08 2006 Chris Lumens 0.14-1 - Remove modes data since this is now in the X server package. rng-utils-1:2.0-1.10 -------------------- * Thu Feb 09 2006 Dave Jones - rebuild. s390utils-2:1.5.0-2.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 2:1.5.0-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes salinfo-1:0.5-1.11_FC5 ---------------------- * Thu Feb 09 2006 Dave Jones - rebuild. syslinux-3.10-2.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 3.10-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes system-config-boot-0.2.11-1.2 ----------------------------- * Tue Feb 07 2006 Jesse Keating - 0.2.11-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes system-config-securitylevel-1.6.15-1 ------------------------------------ * Tue Feb 07 2006 Chris Lumens 1.6.15-1 - Fix firstboot warnings. - Make other services box look better. - Force reboot if SELinux is changed from enabled to disabled in firstboot (#177639). * Tue Feb 07 2006 Jesse Keating - 1.6.14-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes tanukiwrapper-0:3.1.1-4jpp_5fc ------------------------------ * Tue Feb 07 2006 Jesse Keating - 0:3.1.1-4jpp_5fc - rebuilt for new gcc4.1 snapshot and glibc changes * Wed Dec 21 2005 Jesse Keating - 0:3.1.1-4jpp_4fc - rebuilt again tar-1.15.1-12.1 --------------- * Tue Feb 07 2006 Jesse Keating - 1.15.1-12.1 - rebuilt for new gcc4.1 snapshot and glibc changes tog-pegasus-2:2.5-6 ------------------- * Tue Feb 07 2006 Jason Vas Dias - 2:2.5-6 - restore SSLv23_method SSL support now that bug 173399 is fixed - rebuild for new gcc, glibc, glibc-kernheaders - PAMBasicAuthenticatorUnix.cpp includes no longer include syslog.h: add - /usr/bin/install now decides to fail if chown fails - set $INSTALL_USER, $INSTALL_GROUP valgrind-callgrind-0.10.1-1.1 ----------------------------- * Tue Feb 07 2006 Jesse Keating - 0.10.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes x86info-1:1.17-1.20 ------------------- * Thu Feb 09 2006 Dave Jones - rebuild. xen-3.0.1-0.20060208.fc5.1 -------------------------- * Wed Feb 08 2006 Jeremy Katz - 3.0.1-0.20060208.fc5.1 - turn on http listener so you can do things with libvir as a user * Wed Feb 08 2006 Jeremy Katz - 3.0.1-0.20060208.fc5 - update to current hg snapshot for HVM support - update xenguest-install for hvm changes. allow hvm on svm hardware - fix a few little xenguest-install bugs xorg-x11-drv-apm-1.0.1.5-1.1 ---------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-ark-0.5.0.5-1.1 ---------------------------- * Tue Feb 07 2006 Jesse Keating - 0.5.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-chips-1.0.1.3-1.1 ------------------------------ * Tue Feb 07 2006 Jesse Keating - 1.0.1.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-cirrus-1.0.0.5-1.1 ------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-cyrix-1.0.0.5-1.1 ------------------------------ * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-glint-1.0.1.3-1.1 ------------------------------ * Tue Feb 07 2006 Jesse Keating - 1.0.1.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-i128-1.1.0.5-1.1 ----------------------------- * Tue Feb 07 2006 Jesse Keating - 1.1.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-i740-1.0.0.5-1.1 ----------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-neomagic-1.0.0.5-1.1 --------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-nsc-2.7.6.5-2.1 ---------------------------- * Tue Feb 07 2006 Jesse Keating - 2.7.6.5-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-rendition-4.0.1.3-1.1 ---------------------------------- * Tue Feb 07 2006 Jesse Keating - 4.0.1.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-siliconmotion-1.3.1.5-1.1 -------------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.3.1.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-tseng-1.0.0.5-1.1 ------------------------------ * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-v4l-0.0.1.5-1.1 ---------------------------- * Tue Feb 07 2006 Jesse Keating - 0.0.1.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-via-0.1.33.2-1.1 ----------------------------- * Tue Feb 07 2006 Jesse Keating - 0.1.33.2-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-server-1.0.1-6 ----------------------- * Wed Feb 08 2006 Mike A. Harris 1.0.1-6 - Added xorg-x11-server-1.0.1-Red-Hat-extramodes.patch which is a merger of XFree86-4.2.99.2-redhat-custom-modelines.patch and xorg-x11-6.8.2-laptop-modes.patch from FC4 for (#180301) - Install a copy of the vesamodes and extramodes files which contain the list of video modes that are built into the X server, so that the "rhpxl" package does not have to carry around an out of sync copy for itself. (#180301) Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 tkinter - 2.4.2-3.i386 requires libtix8.1.8.4.so Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs tkinter - 2.4.2-3.ia64 requires libtix8.1.8.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- ccs-devel - 1.0.2-3.2.ppc requires ccs = 0:1.0.2-3.2 gulm - 1.0.4-2.FC5.1.ppc requires ccs tkinter - 2.4.2-3.ppc requires libtix8.1.8.4.so Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 tkinter - 2.4.2-3.ppc64 requires libtix8.1.8.4.so()(64bit) Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.4-2.s390 requires kernel >= 0:2.6.9-11 tkinter - 2.4.2-3.s390 requires libtix8.1.8.4.so Broken deps for s390x ---------------------------------------------------------- libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) systemtap - 0.5.4-2.s390x requires kernel >= 0:2.6.9-11 tkinter - 2.4.2-3.s390x requires libtix8.1.8.4.so()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 tkinter - 2.4.2-3.x86_64 requires libtix8.1.8.4.so()(64bit) From pbrobinson at gmail.com Thu Feb 9 15:28:37 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 9 Feb 2006 15:28:37 +0000 Subject: rawhide report: 20060209 changes (part 1/2) In-Reply-To: <200602091507.k19F7p2g012345@porkchop.devel.redhat.com> References: <200602091507.k19F7p2g012345@porkchop.devel.redhat.com> Message-ID: <5256d0b0602090728i7c4a879bta5a8098bc3724199@mail.gmail.com> > gal-1:0.24-6.2 > -------------- > * Tue Feb 07 2006 Jesse Keating - 1:0.24-6.2 > - rebuilt for new gcc4.1 snapshot and glibc changes I may be incorrect but I seem to remember that evolution is the only one that used gal and that with one of the recent releases of evolution that it has been deprecated and hence isn't needed any more. Is there any reason why its still shipped or is it just an oversight? While I don't have quite everything installed nothing depends on it and hence I've removed it on my install without issues. peter From katzj at redhat.com Thu Feb 9 15:44:38 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 09 Feb 2006 10:44:38 -0500 Subject: rawhide report: 20060209 changes (part 1/2) In-Reply-To: <5256d0b0602090728i7c4a879bta5a8098bc3724199@mail.gmail.com> References: <200602091507.k19F7p2g012345@porkchop.devel.redhat.com> <5256d0b0602090728i7c4a879bta5a8098bc3724199@mail.gmail.com> Message-ID: <1139499878.7727.0.camel@orodruin.boston.redhat.com> On Thu, 2006-02-09 at 15:28 +0000, Peter Robinson wrote: > > gal-1:0.24-6.2 > > -------------- > > * Tue Feb 07 2006 Jesse Keating - 1:0.24-6.2 > > - rebuilt for new gcc4.1 snapshot and glibc changes > > I may be incorrect but I seem to remember that evolution is the only > one that used gal and that with one of the recent releases of > evolution that it has been deprecated and hence isn't needed any more. > Is there any reason why its still shipped or is it just an oversight? > While I don't have quite everything installed nothing depends on it > and hence I've removed it on my install without issues. Still required by gnucash Jeremy From mailinglists at erwinrol.com Thu Feb 9 15:48:57 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Thu, 09 Feb 2006 16:48:57 +0100 Subject: rawhide report: 20060209 changes (part 1/2) In-Reply-To: <200602091507.k19F7p2g012345@porkchop.devel.redhat.com> References: <200602091507.k19F7p2g012345@porkchop.devel.redhat.com> Message-ID: <1139500137.8135.154.camel@xpc.home.erwinrol.com> On Thu, 2006-02-09 at 10:07 -0500, Build System wrote: > hardlink-1:1.0-1.20.1 > --------------------- > * Tue Feb 07 2006 Jesse Keating - error: line 4: Tag takes single token only: Release: :.1 1.19.1 > - rebuilt for new gcc4.1 snapshot and glibc changes That looks like something is broken. - Erwin From fedora-devel-list at thebc.ch Thu Feb 9 15:51:12 2006 From: fedora-devel-list at thebc.ch (Steven F. Christ) Date: Thu, 9 Feb 2006 16:51:12 +0100 Subject: GnomeBaker MP3-Support Message-ID: <20060209165112.0931482b@artchaos> Gnomebaker is now avaiable on fedora-extras, is there a way to support MP3? From pbrobinson at gmail.com Thu Feb 9 15:47:44 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 9 Feb 2006 15:47:44 +0000 Subject: rawhide report: 20060209 changes (part 1/2) In-Reply-To: <1139499878.7727.0.camel@orodruin.boston.redhat.com> References: <200602091507.k19F7p2g012345@porkchop.devel.redhat.com> <5256d0b0602090728i7c4a879bta5a8098bc3724199@mail.gmail.com> <1139499878.7727.0.camel@orodruin.boston.redhat.com> Message-ID: <5256d0b0602090747o1dbd9081yfca2befab7c745c7@mail.gmail.com> On 2/9/06, Jeremy Katz wrote: > On Thu, 2006-02-09 at 15:28 +0000, Peter Robinson wrote: > > > gal-1:0.24-6.2 > > > -------------- > > > * Tue Feb 07 2006 Jesse Keating - 1:0.24-6.2 > > > - rebuilt for new gcc4.1 snapshot and glibc changes > > > > I may be incorrect but I seem to remember that evolution is the only > > one that used gal and that with one of the recent releases of > > evolution that it has been deprecated and hence isn't needed any more. > > Is there any reason why its still shipped or is it just an oversight? > > While I don't have quite everything installed nothing depends on it > > and hence I've removed it on my install without issues. > > Still required by gnucash So that would explain why I don't have a need for it then :-) Pete From selinux at gmail.com Thu Feb 9 15:58:28 2006 From: selinux at gmail.com (Tom London) Date: Thu, 9 Feb 2006 07:58:28 -0800 Subject: rawhide report: 20060209 changes (part 1/2) In-Reply-To: <5256d0b0602090747o1dbd9081yfca2befab7c745c7@mail.gmail.com> References: <200602091507.k19F7p2g012345@porkchop.devel.redhat.com> <5256d0b0602090728i7c4a879bta5a8098bc3724199@mail.gmail.com> <1139499878.7727.0.camel@orodruin.boston.redhat.com> <5256d0b0602090747o1dbd9081yfca2befab7c745c7@mail.gmail.com> Message-ID: <4c4ba1530602090758j1f9d3e60ge23b22078d657207@mail.gmail.com> I get this installing today: Cleanup : GConf ##################### [351/638] /sbin/ldconfig: relative path `1' used to build cache error: %postun(GConf-1.0.9-18.i386) scriptlet failed, exit status 1 Cleanup : hdparm ##################### [352/638] From jwboyer at jdub.homelinux.org Thu Feb 9 15:23:57 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 9 Feb 2006 10:23:57 -0500 (EST) Subject: GnomeBaker MP3-Support In-Reply-To: <20060209165112.0931482b@artchaos> References: <20060209165112.0931482b@artchaos> Message-ID: <20804.129.42.161.36.1139498637.squirrel@jdub.homelinux.org> > Gnomebaker is now avaiable on fedora-extras, is there a way to support > MP3? No. http://fedoraproject.org/wiki/ForbiddenItems#head-69c9770fc2ef79ea9a691d03aa2f475eed113bfa josh From bdpepple at ameritech.net Thu Feb 9 16:25:29 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Thu, 09 Feb 2006 11:25:29 -0500 Subject: GnomeBaker MP3-Support In-Reply-To: <20060209165112.0931482b@artchaos> References: <20060209165112.0931482b@artchaos> Message-ID: <1139502330.25708.1.camel@shuttle.273piedmont.org> On Thu, 2006-02-09 at 16:51 +0100, Steven F. Christ wrote: > Gnomebaker is now avaiable on fedora-extras, is there a way to support > MP3? > I believe you need the gstreamer mp3 plug-in. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 9 16:30:06 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 9 Feb 2006 17:30:06 +0100 Subject: GnomeBaker MP3-Support In-Reply-To: <1139502330.25708.1.camel@shuttle.273piedmont.org> References: <20060209165112.0931482b@artchaos> <1139502330.25708.1.camel@shuttle.273piedmont.org> Message-ID: <20060209173006.25d7bcee@python2> Brian Pepple wrote : > On Thu, 2006-02-09 at 16:51 +0100, Steven F. Christ wrote: > > Gnomebaker is now avaiable on fedora-extras, is there a way to support > > MP3? > > > > I believe you need the gstreamer mp3 plug-in. In which case you can grab all you need from here : http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/development/ Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.15-1.1830_FC4 Load : 0.34 0.35 0.30 From michael.favia at insitesinc.com Thu Feb 9 17:10:00 2006 From: michael.favia at insitesinc.com (Michael Favia) Date: Thu, 09 Feb 2006 11:10:00 -0600 Subject: rawhide report: 20060209 changes (part 1/2) In-Reply-To: <200602091507.k19F7p2g012345@porkchop.devel.redhat.com> References: <200602091507.k19F7p2g012345@porkchop.devel.redhat.com> Message-ID: <43EB7768.2080301@insitesinc.com> Build System wrote: > gaim-1:1.5.0-15.fc5 > ------------------- > * Tue Feb 07 2006 Warren Togami 1:1.5.0-15 > - allow compat with gaim-2.x log format (rlaager) > > * Sat Jan 28 2006 David Malcolm 1:1.5.0-14 > - rebuild for new e-d-s > > * Fri Jan 13 2006 Warren Togami 1:1.5.0-13 > - buildreq desktop-file-utils (ivazquez #176688) > - detect NSS in a generic way and abort on failure Beta 2 of gaim 2.0 was released back on the 24th of Jan. Are there any plans for its eventual inclusion in FC5? i have built the RPM provided on the site and have a few annoyances (status trouble, sound issue that might be my card) but fewer then version 1.5. :) -mf From bdpepple at ameritech.net Thu Feb 9 17:14:54 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Thu, 09 Feb 2006 12:14:54 -0500 Subject: GnomeBaker MP3-Support In-Reply-To: <20804.129.42.161.36.1139498637.squirrel@jdub.homelinux.org> References: <20060209165112.0931482b@artchaos> <20804.129.42.161.36.1139498637.squirrel@jdub.homelinux.org> Message-ID: <1139505294.2412.1.camel@shuttle.273piedmont.org> On Thu, 2006-02-09 at 10:23 -0500, Josh Boyer wrote: > > Gnomebaker is now avaiable on fedora-extras, is there a way to support > > MP3? > > No. I believe your wrong. It can be added through a gstreamer plug-in, the mp3 code isn't in gnomebaker. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From andy at warmcat.com Thu Feb 9 17:20:45 2006 From: andy at warmcat.com (Andy Green) Date: Thu, 09 Feb 2006 17:20:45 +0000 Subject: Some numbers on uClibc In-Reply-To: <43EB2360.7030308@warmcat.com> References: <43E87240.9010204@warmcat.com> <1139342822.2952.2.camel@daxter.boston.redhat.com> <43E90E64.20407@warmcat.com> <1139369574.3279.34.camel@daxter.boston.redhat.com> <1139384082.15809.2.camel@rousalka.dyndns.org> <1139384578.3579.39.camel@ender> <1139408681.2584.9.camel@dhcp83-115.boston.redhat.com> <43EA12A8.6060306@warmcat.com> <1139414570.17900.8.camel@dhcp83-115.boston.redhat.com> <43EA234B.2060601@warmcat.com> <5256d0b0602080916o13d09dc5r7d59101c8c6d0762@mail.gmail.com> <43EA2934.6020702@warmcat.com> <1139427443.3130.12.camel@daxter.boston.redhat.com> <20060208123007.1f893b64.zaitcev@redhat.com> <43EA5FBE.6030404@warmcat.com> <20060208164755.291f8d60.zaitcev@redhat.com> <43EB2360.7030308@warmcat.com> Message-ID: <43EB79ED.5070601@warmcat.com> Andy Green wrote: > Pete Zaitcev wrote: > >> Very well, if you say so, ash may be all right. But busybox seems to >> take this too far. You know what the root of all evil is... So why don't >> we let OLPC group to actually build a system and take measurements? >> It seems too early to decide on busybox. For crying out loud, it's I decided to get some numbers to give an idea of what I am going on about. 1) I started trying with FC4 as a basis. This is the minimum packageset for FC4 that includes bash, coreutils. There is a ton of stuff that is not needed at all in the usage scenario for this box. rm -rf testfs ; mkdir -p testfs/dev ; chmod 777 testfs/dev ; mknod testfs/dev/null c 1 3 ; chmod 666 testfs/dev/null ; mknod testfs/dev/zero c 1 5 ; chmod 666 testfs/dev/zero ; rpm -r /usr/src/silentcat-0.2/packages/testfs -i basesystem-8.0-5.noarch.rpm setup-2.5.44-1.1.noarch.rpm rpms/filesystem-2.3.4-1.i386.rpm rpms/libgcc-4.0.2-8.fc4.i386.rpm rpms/bash-3.0-31.i386.rpm rpms/glibc-2.3.5-10.3.i386.rpm rpms/termcap-5.4-7fc4.noarch.rpm rpms/glibc-common-2.3.5-10.3.i386.rpm rpms/tzdata-2005r-3.fc4.noarch.rpm rpms/libtermcap-2.0.8-41.i386.rpm rpms/mktemp-1.5-23.i386.rpm rpms/coreutils-5.2.1-48.1.i386.rpm rpms/findutils-4.2.20-1.i386.rpm rpms/libacl-2.2.32-1.FC4.2.i386.rpm rpms/pam-0.79-9.6.i386.rpm rpms/cracklib-dicts-2.8.2-1.i386.rpm rpms/cracklib-2.8.2-1.i386.rpm rpms/audit-libs-1.0.14-1.fc4.i386.rpm rpms/libselinux-1.23.11-1.1.i386.rpm rpms/sed-4.1.4-1.i386.rpm rpms/initscripts-8.11.1-1.i386.rpm rpms/e2fsprogs-1.38-0.FC4.1.i386.rpm rpms/grep-2.5.1-48.2.i386.rpm rpms/ethtool-3-1.i386.rpm rpms/module-init-tools-3.2-0.pre9.0.FC4.1.i386.rpm rpms/util-linux-2.12p-9.13.i386.rpm rpms/mkinitrd-4.2.15-1.i386.rpm rpms/udev-071-0.FC4.2.i386.rpm rpms/SysVinit-2.85-39.i386.rpm rpms/cpio-2.6-9.FC4.i386.rpm rpms/gzip-1.3.5-6.i386.rpm rpms/lvm2-2.01.08-2.1.i386.rpm rpms/MAKEDEV-3.19-1.i386.rpm rpms/popt-1.10.1-22.i386.rpm rpms/pcre-5.0-4.1.fc4.i386.rpm rpms/libsepol-1.5.10-1.1.i386.rpm rpms/zlib-1.2.2.2-5.fc4.i386.rpm rpms/ncurses-5.4-17.i386.rpm rpms/device-mapper-1.01.02-1.0.i386.rpm rpms/hotplug-2004_09_23-7.i386.rpm rpms/mingetty-1.07-5.i386.rpm rpms/less-394-1.fc4.i386.rpm rpms/readline-5.0-3.i386.rpm rpms/hwdata-0.158.3-1.noarch.rpm rpms/net-tools-1.60-52.fc4.1.i386.rpm rpms/libattr-2.4.24-1.FC4.1.i386.rpm rpms/shadow-utils-4.0.12-6.FC4.i386.rpm rpms/tar-1.15.1-11.FC4.i386.rpm rpms/kernel-2.6.15-1.1831_FC4.i586.rpm rpms/chkconfig-1.3.23-0.4.i386.rpm rpms/fedora-release-4-2.noarch.rpm rpms/iputils-20020927-22.i386.rpm rpms/gawk-3.1.4-5.3.i386.rpm rpms/info-4.8-8.fc4.1.i386.rpm rpms/psmisc-21.5-5.i386.rpm rpms/sysklogd-1.4.1-30.i386.rpm rpms/procps-3.2.5-6.3.i386.rpm rpms/iproute-2.6.11-1.i386.rpm rpms/db4-4.3.27-3.i386.rpm rpms/libstdc++-4.0.2-8.fc4.i386.rpm # du testfs -h --exclude proc --exclude dev -s 186M testfs 2) This is an i386 busybox with most mod cons and locale support, still using FC4 glibc (notice stuff like selinux libs, db4 and initscripts are gone) rm -rf testfs ; mkdir -p testfs/dev ; chmod 777 testfs/dev ; mknod testfs/dev/null c 1 3 ; chmod 666 testfs/dev/null ; mknod testfs/dev/zero c 1 5 ; chmod 666 testfs/dev/zero ; rpm -r /usr/src/silentcat-0.2/packages/testfs -i basesystem-8.0-5.noarch.rpm setup-2.5.44-1.1.noarch.rpm rpms/filesystem-2.3.4-1.i386.rpm rpms/libgcc-4.0.2-8.fc4.i386.rpm /home/packager/rpm/RPMS/i386/busybox-1.1.0-21.i386.rpm rpms/zlib-1.2.2.2-5.fc4.i386.rpm rpms/glibc-2.3.5-10.3.i386.rpm rpms/glibc-common-2.3.5-10.3.i386.rpm rpms/tzdata-2005r-3.fc4.noarch.rpm # du testfs -h --exclude proc --exclude dev -s 107M testfs 3) This is an i386 uclibc + busybox minimal filesystem, with ash, most coreutils, common goodies like network, ifconfig, udhcpc, modprobe, etc, etc. Without kernel though, which will be an extra 1.2MB or thereabouts. It has various libs including libstdc++, and libc provided by uclibc. $ du -h build_i386/root -s 3.7M build_i386/root -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From gianluca.cecchi at gmail.com Thu Feb 9 17:32:47 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Thu, 9 Feb 2006 18:32:47 +0100 Subject: GnomeBaker MP3-Support Message-ID: <561c252c0602090932j49a12c4fq@mail.gmail.com> On Thu, 9 Feb 2006 17:30:06 +0100 Matthias Saou wrote: > In which case you can grab all you need from here : > http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/development/ In the sense that one should download gstreamer-ffmpeg src.rpm and then recompile for fc5? From linux_4ever at yahoo.com Thu Feb 9 18:13:11 2006 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 9 Feb 2006 10:13:11 -0800 (PST) Subject: auid In-Reply-To: <1139507669.2872.227.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20060209181311.33727.qmail@web51513.mail.yahoo.com> >so in the absence of SELinux (e.g. CAPP-only configuration), any uid 0 process >can mutate its loginuid later to mask the original one, Or it can delete the audit logs or re-write syslog or install a rootkit covering everything up. The only defence against this kind of tampering is remote logging. >and in the presence of SELinux, any program authorized for audit_control can >mutate its loginuid later (so a smaller exposure, but still a possibility). So...why doesn't policy restrict this even further so that the 10 apps that need to set this are the *only* ones that can do so? The list is: login, sshd, vsftpd, postfix, procmail, cron, at, gdm, kdm, & xdm. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From paul at city-fan.org Thu Feb 9 18:18:09 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 09 Feb 2006 18:18:09 +0000 Subject: auid In-Reply-To: <20060209181311.33727.qmail@web51513.mail.yahoo.com> References: <20060209181311.33727.qmail@web51513.mail.yahoo.com> Message-ID: <43EB8761.3000704@city-fan.org> Steve G wrote: >>so in the absence of SELinux (e.g. CAPP-only configuration), any uid 0 process >>can mutate its loginuid later to mask the original one, > > > Or it can delete the audit logs or re-write syslog or install a rootkit covering > everything up. The only defence against this kind of tampering is remote logging. > > >>and in the presence of SELinux, any program authorized for audit_control can >>mutate its loginuid later (so a smaller exposure, but still a possibility). > > > So...why doesn't policy restrict this even further so that the 10 apps that need > to set this are the *only* ones that can do so? > > The list is: login, sshd, vsftpd, postfix, procmail, cron, at, gdm, kdm, & xdm. That might break any alternatives to these programs, e.g. from Fedora Extras, such as proftpd, wouldn't it? Paul. From linux_4ever at yahoo.com Thu Feb 9 18:23:43 2006 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 9 Feb 2006 10:23:43 -0800 (PST) Subject: auid In-Reply-To: <43EB8761.3000704@city-fan.org> Message-ID: <20060209182343.37733.qmail@web51513.mail.yahoo.com> >That might break any alternatives to these programs, e.g. from Fedora >Extras, such as proftpd, wouldn't it? Proftpd has never been modified (by us) to set the loginuid. Not that it can't be done...it just hasn't. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 9 18:24:45 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 9 Feb 2006 19:24:45 +0100 Subject: GnomeBaker MP3-Support In-Reply-To: <561c252c0602090932j49a12c4fq@mail.gmail.com> References: <561c252c0602090932j49a12c4fq@mail.gmail.com> Message-ID: <20060209192445.4beaafcb@python2> Gianluca Cecchi wrote : > On Thu, 9 Feb 2006 17:30:06 +0100 Matthias Saou spam spam spam spam egg and spam freshrpms net> wrote: > > > In which case you can grab all you need from here : > > http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/development/ > > In the sense that one should download gstreamer-ffmpeg src.rpm and > then recompile for fc5? Nope, those packages are already all made for "development" (hence the directory name), and in this case the package you'll need is the gstreamer-plugins-ugly IIRC (or -bad, I keep confusing them). Since there are quite a few dependencies, you might want to create a /etc/yum.repos.d/freshrpms.repo file and use yum : [freshrpms] name=Fedora Core $releasever - $basearch - Freshrpms baseurl=http://ayo.freshrpms.net/fedora/linux/development/$basearch/freshrpms/ enabled=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-freshrpms gpgcheck=1 Note that packages are not yet available for PPC, but will be when all packages get rebuilt on the final FC5. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.15-1.1830_FC4 Load : 0.56 0.52 0.45 From jkeating at redhat.com Thu Feb 9 18:33:56 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 09 Feb 2006 10:33:56 -0800 Subject: rawhide report: 20060209 changes (part 1/2) In-Reply-To: <1139500137.8135.154.camel@xpc.home.erwinrol.com> References: <200602091507.k19F7p2g012345@porkchop.devel.redhat.com> <1139500137.8135.154.camel@xpc.home.erwinrol.com> Message-ID: <1139510036.2659.14.camel@ender> On Thu, 2006-02-09 at 16:48 +0100, Erwin Rol wrote: > > > hardlink-1:1.0-1.20.1 > > --------------------- > > * Tue Feb 07 2006 Jesse Keating - error: line 4: Tag takes single token only: Release: :.1 1.19.1 > > - rebuilt for new gcc4.1 snapshot and glibc changes > > That looks like something is broken. Hrm yes. Something in the snippit of code I have to handle epocs for changelog entries. Odd that this package was ok, but others aren't. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwboyer at jdub.homelinux.org Thu Feb 9 17:35:51 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 9 Feb 2006 12:35:51 -0500 (EST) Subject: GnomeBaker MP3-Support In-Reply-To: <1139505294.2412.1.camel@shuttle.273piedmont.org> References: <20060209165112.0931482b@artchaos> <20804.129.42.161.36.1139498637.squirrel@jdub.homelinux.org> <1139505294.2412.1.camel@shuttle.273piedmont.org> Message-ID: <35905.129.42.161.36.1139506551.squirrel@jdub.homelinux.org> > On Thu, 2006-02-09 at 10:23 -0500, Josh Boyer wrote: >> > Gnomebaker is now avaiable on fedora-extras, is there a way to support >> > MP3? >> >> No. > > > I believe your wrong. It can be added through a gstreamer plug-in, the > mp3 code isn't in gnomebaker. I know that. I was heading off the "can we put it in Fedora Extras" question with the URL I had in my original message. Suppose I could have explained that a bit better. josh From pbrobinson at gmail.com Thu Feb 9 18:43:04 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 9 Feb 2006 18:43:04 +0000 Subject: artifacts in gtk apps and slowness updating Message-ID: <5256d0b0602091043s43166852k41fcdf884da32d38@mail.gmail.com> Hi All, Is it just me seeing artifacts in various gtk components on rawhide with all updates? Its been there a while. I'm seeing it in things like progess bars and the forward and back buttons on firefox. Also when I switch to a terminal window it seems to take forever to refresh and show the contents of the window. Peter From fedora at adslpipe.co.uk Thu Feb 9 18:44:08 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Thu, 09 Feb 2006 18:44:08 +0000 Subject: CD/DVD Burning In-Reply-To: <1139122784.10660.1.camel@tuxhugger> References: <1139103787.3319.5.camel@xpc.home.erwinrol.com><43E56AED.9060702@adslpipe.co.uk><200602050743.34202.bogdan.mustiata@gmail.com><1139119142.2765.3.camel@pingu.homenetwork.lan> <1139122784.10660.1.camel@tuxhugger> Message-ID: <43EB8D78.9050108@adslpipe.co.uk> Peter Gordon wrote: > GnomeBaker is currently being reviewed for Extras. OK, I noticed that GnomeBaker was accepted into Extras, so I installed it today, it erased and wrote a .iso to CD-RW for me OK, not tested anything else with it, I'd say it's a nice start, but it isn't going to deplose k3b for me just yet ... From pjones at redhat.com Thu Feb 9 18:53:59 2006 From: pjones at redhat.com (Peter Jones) Date: Thu, 09 Feb 2006 13:53:59 -0500 Subject: initscripts-8.26-1 breaks old alias interface naming scheme In-Reply-To: <1139490921.3532.9.camel@kloczek01.pracownicy.zie> References: <1139490921.3532.9.camel@kloczek01.pracownicy.zie> Message-ID: <1139511239.8320.4.camel@localhost.localdomain> On Thu, 2006-02-09 at 14:15 +0100, Tomasz K?oczko wrote: > Today I discover new initscripts-8.26-1 breaks old network alias > interfaces naming scheme. > > In previouse version was powinble name alias interface like eth0:foobar > > In current iniscritps in /etc/sysconfig/network-scripts/ifup-aliases is: > > > if [[ ! "$DEVNUM" =~ '^[0123456789]*$' ]]; then > echo $"error in $FILE: invalid alias number" >&2 > return 1 > fi > > I think it can break many systems on upgrade to FC5. > After commenting above old initscripts behavior is sill workig > correctly. Yeah, looks pretty sketchy. I think this is more correct for the bug it's trying to solve, but I'll let notting say for sure: Index: ifup-aliases =================================================================== RCS file: /usr/local/CVS/initscripts/sysconfig/network-scripts/ifup-aliases,v retrieving revision 1.40 diff -u -p -r1.40 ifup-aliases --- ifup-aliases 3 Feb 2006 02:01:32 -0000 1.40 +++ ifup-aliases 9 Feb 2006 18:36:43 -0000 @@ -149,11 +149,6 @@ function new_interface () IPGLOP="${ipa%%.*}_${ipb%%.*}_${ipc%%.*}_${ipc#*.}"; DEVNUM=${DEVICE#*:} - if [[ ! "$DEVNUM" =~ '^[0123456789]*$' ]]; then - echo $"error in $FILE: invalid alias number" >&2 - return 1 - fi - eval " ipseen=\$ipseen_${IPGLOP}; devseen=\$devseen_${DEVNUM}; ipseen_${IPGLOP}=$FILE; devseen_${DEVNUM}=$FILE; @@ -302,7 +297,7 @@ for FILE in ifcfg-${parent_device}:*[^~] ini_env; . $FILE; [ -z "$DEVICE" ] && DEVICE=${FILE##ifcfg-} - [ "$ONPARENT" != "no" -a "$ONPARENT" != "NO" ] && new_interface; + [[ ! "$ONPARENT" =~ "NO|no" ]] && [ "$DEVICE" == "${FILE##ifcfg-}" ] && new_interface; unset DEVICE done -- Peter From pjones at redhat.com Thu Feb 9 19:05:12 2006 From: pjones at redhat.com (Peter Jones) Date: Thu, 09 Feb 2006 14:05:12 -0500 Subject: initscripts-8.26-1 breaks old alias interface naming scheme In-Reply-To: <1139511239.8320.4.camel@localhost.localdomain> References: <1139490921.3532.9.camel@kloczek01.pracownicy.zie> <1139511239.8320.4.camel@localhost.localdomain> Message-ID: <1139511913.6873.0.camel@localhost.localdomain> On Thu, 2006-02-09 at 13:53 -0500, Peter Jones wrote: > Yeah, looks pretty sketchy. I think this is more correct for the bug > it's trying to solve, but I'll let notting say for sure: Actually, I went ahead and applied it in CVS. Bill knows how to revert if he doesn't like it ;) -- Peter From wtogami at redhat.com Thu Feb 9 20:15:35 2006 From: wtogami at redhat.com (Warren Togami) Date: Thu, 09 Feb 2006 10:15:35 -1000 Subject: rawhide report: 20060209 changes (part 1/2) In-Reply-To: <43EB7768.2080301@insitesinc.com> References: <200602091507.k19F7p2g012345@porkchop.devel.redhat.com> <43EB7768.2080301@insitesinc.com> Message-ID: <43EBA2E7.1060109@redhat.com> Michael Favia wrote: > Build System wrote: >> gaim-1:1.5.0-15.fc5 >> ------------------- >> * Tue Feb 07 2006 Warren Togami 1:1.5.0-15 >> - allow compat with gaim-2.x log format (rlaager) >> >> * Sat Jan 28 2006 David Malcolm 1:1.5.0-14 >> - rebuild for new e-d-s >> >> * Fri Jan 13 2006 Warren Togami 1:1.5.0-13 >> - buildreq desktop-file-utils (ivazquez #176688) >> - detect NSS in a generic way and abort on failure > > Beta 2 of gaim 2.0 was released back on the 24th of Jan. Are there any > plans for its eventual inclusion in FC5? i have built the RPM provided > on the site and have a few annoyances (status trouble, sound issue that > might be my card) but fewer then version 1.5. :) -mf > No plans when upstream says it isn't ready, and we need to ship something stable in FC5 final. Might consider upgrading it to gaim2 later after FC5 release if it is in good shape. Warren Togami wtogami at redhat.com From fedora at camperquake.de Thu Feb 9 20:57:18 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 9 Feb 2006 21:57:18 +0100 Subject: artifacts in gtk apps and slowness updating In-Reply-To: <5256d0b0602091043s43166852k41fcdf884da32d38@mail.gmail.com> References: <5256d0b0602091043s43166852k41fcdf884da32d38@mail.gmail.com> Message-ID: <20060209215718.3c47ca86@nausicaa.camperquake.de> Hi. Peter Robinson wrote: > Is it just me seeing artifacts in various gtk components on rawhide > with all updates? Its been there a while. Artifacts like what? I occassionally see thin, horizontal black streaks (1 pixel high, ~200px long or so) when scrolling around in sylpheed or firefox. I also see them right now while typing this mail in sylpheed (just when I hit a key, though.) -- Confucius say, "Man who quote me is fool." From russell at coker.com.au Thu Feb 9 21:06:27 2006 From: russell at coker.com.au (Russell Coker) Date: Fri, 10 Feb 2006 08:06:27 +1100 Subject: auid In-Reply-To: <20060209181311.33727.qmail@web51513.mail.yahoo.com> References: <20060209181311.33727.qmail@web51513.mail.yahoo.com> Message-ID: <200602100806.40386.russell@coker.com.au> On Friday 10 February 2006 05:13, Steve G wrote: > >so in the absence of SELinux (e.g. CAPP-only configuration), any uid 0 > > process can mutate its loginuid later to mask the original one, > > Or it can delete the audit logs or re-write syslog or install a rootkit > covering everything up. The only defence against this kind of tampering is > remote logging. > > >and in the presence of SELinux, any program authorized for audit_control > > can mutate its loginuid later (so a smaller exposure, but still a > > possibility). > > So...why doesn't policy restrict this even further so that the 10 apps that > need to set this are the *only* ones that can do so? > > The list is: login, sshd, vsftpd, postfix, procmail, cron, at, gdm, kdm, & > xdm. Also every other mail server including Sendmail. The Postfix code supports multiple deliveries initiated from the one local process and I wrote code to reset the auid for this. This is one thing that I think is a bad idea, in fact I'll suggest to Wietse that Postfix be changed to only have one delivery per instance of the local process, fork() is cheap by any measure and particularly when compared to all the synchronous disk IO that occurs when a mail server is doing delivery. Does procmail really need this? As for Sendmail, one program which does EVERYTHING including the ability to reset auid. -- 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 Thu Feb 9 21:26:32 2006 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 9 Feb 2006 13:26:32 -0800 (PST) Subject: auid In-Reply-To: <200602100806.40386.russell@coker.com.au> Message-ID: <20060209212633.62002.qmail@web51504.mail.yahoo.com> >Also every other mail server including Sendmail. Are they modified to set loginuid? >The Postfix code supports multiple deliveries initiated from the one local >process and I wrote code to reset the auid for this. This is one thing that >I think is a bad idea, in fact I'll suggest to Wietse that Postfix be changed >to only have one delivery per instance of the local process, fork() is cheap >by any measure and particularly when compared to all the synchronous disk IO >that occurs when a mail server is doing delivery. The only issue is to make sure that when it does any processing of .files on behalf of a user, the loginuid is set for that user during the processing of the script. After that, postfix should go back to its original loginuid. >Does procmail really need this? For situations where there is no mail server installed and cron jobs need to deliver the mail. If there's a way to avoid procmail when there's no postfix installed, then we don't need it. >As for Sendmail, one program which does EVERYTHING including the ability to >reset auid. Is sendmail modified? -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From benjy.grogan at gmail.com Fri Feb 10 00:21:32 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Thu, 9 Feb 2006 19:21:32 -0500 Subject: XGL In-Reply-To: <1139218686.9515.8.camel@price.stavtrup-st.dk> References: <43E15BEF.3070405@mharris.ca> <58d389c20602052158k7830e344v3598723df964cda8@mail.gmail.com> <1139218543.9515.6.camel@price.stavtrup-st.dk> <1139218686.9515.8.camel@price.stavtrup-st.dk> Message-ID: There are some cool Xgl demos at Benji On 2/6/06, David Nielsen wrote: > > man, 06 02 2006 kl. 10:35 +0100, skrev David Nielsen: > > > Does anyone know if there will be streams or captured videos of the > > XDevConf talks? > > Answering myself: > > http://freedesktop.org/wiki/Software/XDevConf/Cambridge2005 > > -- > Obligatory shameless blog plug - the GNOME commentary located at: > www.lovesunix.net/blog > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjy.grogan at gmail.com Fri Feb 10 00:29:58 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Thu, 9 Feb 2006 19:29:58 -0500 Subject: XGL In-Reply-To: <43E15BEF.3070405@mharris.ca> References: <43E15BEF.3070405@mharris.ca> Message-ID: On 2/1/06, Mike A. Harris wrote: > > Benjy Grogan wrote: > > I hear that in a week or so Novell will be releasing the source code to > > XGL for X11 7.0. Will it be possible to have XGL available in Extras > > for FC5? I'm guessing it's one of those new X11 modules that v7.0 is > > all about. But I know little about XGL and would like to test it out to > > know more. It's going to be in NLD 10 in a few months. > > There are a lot of X related "goodies" that are up and coming in the > X development world, including technologies being developed by Red Hat, > Novell, Sun, and various others in the community. The current plan for > Fedora Core 5, is to ship X11R7.0 as the official X implementation, > including the Xorg X server. > > The various developmental/experimental technologies being developed > by the above parties will most likely be available to Fedora users in > one form or another over time, however everything is quite experimental > at the current point in time to make any solid speculation for the > inclusion of other components into Fedora Core 5 at this time. > Maybe Fedora could do something like was done with SELinux? Where it was available in FC2 but not by default. In an update for X11 from 7.0 to 7.1for FC5 the Xgl branch could be included along with instructions on how to enable it. This is how Novell will be introducing Xgl to it's NLD10 distribution. It seems like a good way to get Xgl tested early and it's the perfect place for it to take place, in Fedora. I'm eager to see how Xgl works. :) And then I guess compiz would be the next request. ;) Benji -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitr at volny.cz Fri Feb 10 02:03:58 2006 From: mitr at volny.cz (Miloslav Trmac) Date: Fri, 10 Feb 2006 03:03:58 +0100 Subject: initscripts-8.26-1 breaks old alias interface naming scheme In-Reply-To: <1139490921.3532.9.camel@kloczek01.pracownicy.zie> References: <1139490921.3532.9.camel@kloczek01.pracownicy.zie> Message-ID: <43EBF48E.5090804@volny.cz> Tomasz K?oczko wrote: > Today I discover new initscripts-8.26-1 breaks old network alias > interfaces naming scheme. > > In previouse version was powinble name alias interface like eth0:foobar Actually the code didn't quite support it; I have fixed both the check and the rest of the code in CVS. Thanks, Mirek From amit_ml at rajgad.com Fri Feb 10 02:27:05 2006 From: amit_ml at rajgad.com (Amit D. Chaudhary) Date: Thu, 09 Feb 2006 18:27:05 -0800 Subject: Kernel BUG at "mm/page_alloc.c":413 due to invalid operand: 0000 on AMD 64 Message-ID: <43EBF9F9.7030101@rajgad.com> Hi, While using a program that does lot of file manipulation on a dual processor AMD Opteron system, the system reboots. During one of the two times it happened, the following ended up in the /var/log/messages. The problem is not reproducible, it just happens in a few days. The kernel is from Fedora Core 3, but not the latest. There are no other kernel modules. I have searched on the mailing lists, but nothing specific to this. Any ideas on what might be wrong? Thanks Amit Kernel version: Feb 6 10:45:54 GEN kernel: Linux version 2.6.12-1.1372_FC3smp (bhcompile at crowe.devel.redhat.com) (gcc version 3.4.3 20050227 (Red Hat 3.4.3-22)) #1 SMP Fri Jul 15 01:08:54 EDT 2005 Feb 2 18:55:47 nc-analyzer kernel: ----------- [cut here ] --------- [please bite here ] --------- Feb 2 18:55:47 nc-analyzer kernel: Kernel BUG at "mm/page_alloc.c":413 Feb 2 18:55:47 nc-analyzer kernel: invalid operand: 0000 [1] SMP Feb 2 18:55:47 nc-analyzer kernel: CPU 0 Feb 2 18:55:47 nc-analyzer kernel: Modules linked in: md5 ipv6 ipt_REJECT ipt_state ip_conntrack iptable_filter ip_tables dm_mod video button battery ac ohci_hcd i2c_amd8111 i2c_core hw_random tg3 floppy ext3 jbd 3w_9xxx sd_mod scsi_mod Feb 2 18:55:47 nc-analyzer kernel: Pid: 3161, comm: AgentEventRecor Not tainted 2.6.12-1.1372_FC3smp Feb 2 18:55:47 nc-analyzer kernel: RIP: 0010:[] {__rmqueue+196} Feb 2 18:55:47 nc-analyzer kernel: RSP: 0018:ffff81024a149a18 EFLAGS: 00010002 Feb 2 18:55:47 nc-analyzer kernel: RAX: 0000000000000001 RBX: ffff810000017418 RCX: ffff810000015000 Feb 2 18:55:47 nc-analyzer kernel: RDX: 000000000012d340 RSI: 0000000000001000 RDI: ffff810000016300 Feb 2 18:55:47 nc-analyzer kernel: RBP: ffff8100051e3600 R08: 0000000000000001 R09: 0000000000000001 Feb 2 18:55:47 nc-analyzer kernel: R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000040 Feb 2 18:55:47 nc-analyzer kernel: R13: 0000000000000006 R14: ffff810000016300 R15: ffff8100051e2800 Feb 2 18:55:47 nc-analyzer kernel: FS: 00002aaaaba8b3a0(0000) GS:ffffffff80502200(0000) knlGS:0000000000000000 Feb 2 18:55:47 nc-analyzer kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b Feb 2 18:55:47 nc-analyzer kernel: CR2: 000000000069d000 CR3: 000000012d23f000 CR4: 00000000000006e0 Feb 2 18:55:47 nc-analyzer kernel: Process AgentEventRecor (pid: 3161, threadinfo ffff81024a148000, task ffff8102fbd99840) Feb 2 18:55:47 nc-analyzer kernel: Stack: 0000000000000286 ffff810000016380 ffff810000016300 0000000000000000 Feb 2 18:55:47 nc-analyzer kernel: ffff810000016390 0000000000000002 0000000000000000 ffffffff8016692c Feb 2 18:55:47 nc-analyzer kernel: 0000000000000292 ffff810000017380 Feb 2 18:55:47 nc-analyzer kernel: Call Trace:{buffered_rmqueue+172} {__alloc_pages+231} Feb 2 18:55:47 nc-analyzer kernel: {generic_file_buffered_write+417} Feb 2 18:55:47 nc-analyzer kernel: {current_fs_time+85} {copy_user_generic_c+8} Feb 2 18:55:47 nc-analyzer kernel: {inode_update_time+62} {__generic_file_aio_write_nolock+970} Feb 2 18:55:47 nc-analyzer kernel: {file_read_actor+0} {__generic_file_write_nolock+158} Feb 2 18:55:47 nc-analyzer kernel: {__generic_file_aio_read+431} {do_no_page+879} Feb 2 18:55:47 nc-analyzer kernel: {autoremove_wake_function+0} {do_sync_read+173} Feb 2 18:55:47 nc-analyzer kernel: {generic_file_writev+117} {do_readv_writev+399} Feb 2 18:55:47 nc-analyzer kernel: {do_sync_write+0} {thread_return+155} Feb 2 18:55:47 nc-analyzer kernel: {autoremove_wake_function+0} {dnotify_parent+46} Feb 2 18:55:47 nc-analyzer kernel: {sys_writev+83} {system_call+126} Feb 2 18:55:47 nc-analyzer kernel: Feb 2 18:55:47 nc-analyzer kernel: Feb 2 18:55:47 nc-analyzer kernel: Code: 0f 0b 77 01 37 80 ff ff ff ff 9d 01 48 8b 13 48 8d 45 28 48 Feb 2 18:55:47 nc-analyzer kernel: RIP {__rmqueue+196} RSP Feb 2 18:55:47 nc-analyzer kernel: <3>Debug: sleeping function called from invalid context at include/linux/rwsem.h:43 Feb 2 18:55:47 nc-analyzer kernel: in_atomic():0, irqs_disabled():1 Feb 2 18:55:47 nc-analyzer kernel: Feb 2 18:55:47 nc-analyzer kernel: Call Trace:{__might_sleep+197} {profile_task_exit+41} Feb 2 18:55:47 nc-analyzer kernel: {do_exit+34} {do_unblank_screen+53} Feb 2 18:55:47 nc-analyzer kernel: {die+77} {do_invalid_op+145} Feb 2 18:55:47 nc-analyzer kernel: {__rmqueue+196} {:jbd:do_get_write_access+1446} Feb 2 18:55:47 nc-analyzer kernel: {error_exit+0} {__rmqueue+196} Feb 2 18:55:47 nc-analyzer kernel: {__rmqueue+192} {buffered_rmqueue+172} Feb 2 18:55:47 nc-analyzer kernel: {__alloc_pages+231} {generic_file_buffered_write+417} Feb 2 18:55:47 nc-analyzer kernel: {current_fs_time+85} {copy_user_generic_c+8} Feb 2 18:55:47 nc-analyzer kernel: {inode_update_time+62} {__generic_file_aio_write_nolock+970} Feb 2 18:55:47 nc-analyzer kernel: {file_read_actor+0} {__generic_file_write_nolock+158} Feb 2 18:55:47 nc-analyzer kernel: {__generic_file_aio_read+431} {do_no_page+879} Feb 2 18:55:47 nc-analyzer kernel: {autoremove_wake_function+0} {do_sync_read+173} Feb 2 18:55:47 nc-analyzer kernel: {generic_file_writev+117} {do_readv_writev+399} Feb 2 18:55:47 nc-analyzer kernel: {do_sync_write+0} {thread_return+155} Feb 2 18:55:47 nc-analyzer kernel: {autoremove_wake_function+0} {dnotify_parent+46} Feb 2 18:55:47 nc-analyzer kernel: {sys_writev+83} {system_call+126} Feb 2 18:55:47 nc-analyzer kernel: From naoki at valuecommerce.com Fri Feb 10 02:51:43 2006 From: naoki at valuecommerce.com (Naoki) Date: Fri, 10 Feb 2006 11:51:43 +0900 Subject: Linux-HA? (Now with cluster questions!). In-Reply-To: <43EB41F3.40803@redhat.com> References: <1139453765.17114.103.camel@dragon.sys.intra> <43EAB20D.3060703@redhat.com> <1139464964.17114.159.camel@dragon.sys.intra> <43EB41F3.40803@redhat.com> Message-ID: <1139539904.2297.26.camel@dragon.sys.intra> Tim, and Mr Hollis, Thanks for putting me right. I'll check out the shipping cluster (GFS) software and I'm sure it do the job. If not, I'll go with David's suggestion of submitting heartbeat for inclusion to extras. Cheers. From dax at gurulabs.com Fri Feb 10 04:01:48 2006 From: dax at gurulabs.com (Dax Kelson) Date: Thu, 09 Feb 2006 21:01:48 -0700 Subject: gaim (was: rawhide report: 20060209 changes) In-Reply-To: <43EBA2E7.1060109@redhat.com> References: <200602091507.k19F7p2g012345@porkchop.devel.redhat.com> <43EB7768.2080301@insitesinc.com> <43EBA2E7.1060109@redhat.com> Message-ID: <1139544108.3580.18.camel@mentorng.gurulabs.com> On Thu, 2006-02-09 at 10:15 -1000, Warren Togami wrote: > No plans when upstream says it isn't ready, and we need to ship > something stable in FC5 final. Might consider upgrading it to gaim2 > later after FC5 release if it is in good shape. > > Warren Togami The gaim 2.0 betas support Cyrus-SASL and GSSAPI/Kerberos authentication with Jabber. You get the standard single sign-on bliss and solve the plain text password stored in ~/.gaim/accounts.xml problem. If FC5 is shipping gaim v1.5 would you apply a patch to it to add GSSAPI/Kerberos Jabber authentication support? We use both 2.0 beta and the 1.5+patch here at our office against our kerberized Jabber server. We love it. Dax Kelson Guru Labs From rodd at clarkson.id.au Fri Feb 10 04:33:10 2006 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Fri, 10 Feb 2006 15:33:10 +1100 Subject: GnomeBaker MP3-Support In-Reply-To: <20060209192445.4beaafcb@python2> References: <561c252c0602090932j49a12c4fq@mail.gmail.com> <20060209192445.4beaafcb@python2> Message-ID: <1139545991.2484.14.camel@localhost.localdomain> On Thu, 2006-02-09 at 19:24 +0100, Matthias Saou wrote: > Nope, those packages are already all made for "development" (hence the > directory name), and in this case the package you'll need is the > gstreamer-plugins-ugly IIRC (or -bad, I keep confusing them). There's three good: drivers work and also won't cause licensing issues bad: drivers work but may cause licensing issues ugly: drivers may work to some degree, licensing either/or. r. -- "It's a fine line between denial and faith. It's much better on my side" From jarod at wilsonet.com Fri Feb 10 06:52:00 2006 From: jarod at wilsonet.com (Jarod Wilson) Date: Thu, 9 Feb 2006 22:52:00 -0800 Subject: Linux-HA? In-Reply-To: <1139493955.2717.14.camel@dhollis-lnx.sunera.com> References: <1139453765.17114.103.camel@dragon.sys.intra> <1139493955.2717.14.camel@dhollis-lnx.sunera.com> Message-ID: On Feb 09, 2006, at 06:05, David Hollis wrote: > On Thu, 2006-02-09 at 11:56 +0900, Naoki wrote: >> Hey all, >> >> Does Fedora plan on shipping Linux-HA ( heartbeat )? Or is there a >> replacement / similar package which is otherwise recommended ? > > If you do want to use heartbeat, it includes a working spec file in > the > tar.gz so you can build your own RPM with 'rpmbuild -ta > heartbeat-1.0.5.tar.gz' or the like. Wouldn't be bad to be in extras > though, it is quite useful and isn't big or require a boatload of > dependencies. I've got a ton of cluster-related packages I hope to get into Fedora Extras after I get settled into a new job I'll be starting in a few weeks... -- Jarod Wilson jarod at wilsonet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From wtogami at redhat.com Fri Feb 10 08:11:05 2006 From: wtogami at redhat.com (Warren Togami) Date: Thu, 09 Feb 2006 22:11:05 -1000 Subject: gaim In-Reply-To: <1139544108.3580.18.camel@mentorng.gurulabs.com> References: <200602091507.k19F7p2g012345@porkchop.devel.redhat.com> <43EB7768.2080301@insitesinc.com> <43EBA2E7.1060109@redhat.com> <1139544108.3580.18.camel@mentorng.gurulabs.com> Message-ID: <43EC4A99.8060206@redhat.com> Dax Kelson wrote: > On Thu, 2006-02-09 at 10:15 -1000, Warren Togami wrote: >> No plans when upstream says it isn't ready, and we need to ship >> something stable in FC5 final. Might consider upgrading it to gaim2 >> later after FC5 release if it is in good shape. >> >> Warren Togami > > The gaim 2.0 betas support Cyrus-SASL and GSSAPI/Kerberos authentication > with Jabber. You get the standard single sign-on bliss and solve the > plain text password stored in ~/.gaim/accounts.xml problem. > > If FC5 is shipping gaim v1.5 would you apply a patch to it to add > GSSAPI/Kerberos Jabber authentication support? > > We use both 2.0 beta and the 1.5+patch here at our office against our > kerberized Jabber server. We love it. > > Dax Kelson > Guru Labs > I will patch gaim-1.5.x only if upstream gaim includes the patch in CVS of that branch. I will not diverge from upstream. Warren Togami wtogami at redhat.com From emeric.maschino at jouy.inra.fr Fri Feb 10 08:37:55 2006 From: emeric.maschino at jouy.inra.fr (Emeric Maschino) Date: Fri, 10 Feb 2006 09:37:55 +0100 Subject: artifacts in gtk apps and slowness updating In-Reply-To: <5256d0b0602091043s43166852k41fcdf884da32d38@mail.gmail.com> References: <5256d0b0602091043s43166852k41fcdf884da32d38@mail.gmail.com> Message-ID: <1139560675.5054.1.camel@localhost.localdomain> Hi, > Is it just me seeing artifacts in various gtk components on rawhide > with all updates? Its been there a while. I'm seeing it in things like > progess bars and the forward and back buttons on firefox. Also when I > switch to a terminal window it seems to take forever to refresh and > show the contents of the window. Nothing similar here with up-to-date Rawhide (on an ia64 system though). Could this be related to a particular video adapter? Did you try the vesa driver to check if these artifacts are also noticeable? Hope this helps, ?meric From gianluca.cecchi at gmail.com Fri Feb 10 09:18:46 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Fri, 10 Feb 2006 10:18:46 +0100 Subject: GnomeBaker MP3-Support Message-ID: <561c252c0602100118h2a21850ct@mail.gmail.com> On Thu, 9 Feb 2006 19:24:45 +0100 Matthias Saou wrote: > Nope, those packages are already all made for "development" So that the fc4 label in binary rpms name: gstreamer-plugins-bad-0.10.0.1-1.2.fc4.1.i386.rpm is ininfluent and one can install on rawhide as is? From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 10 12:24:43 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 10 Feb 2006 13:24:43 +0100 Subject: GnomeBaker MP3-Support In-Reply-To: <561c252c0602100118h2a21850ct@mail.gmail.com> References: <561c252c0602100118h2a21850ct@mail.gmail.com> Message-ID: <20060210132443.786f3c8e@python2> Gianluca Cecchi wrote : > On Thu, 9 Feb 2006 19:24:45 +0100 Matthias Saou spam spam spam spam egg and spam freshrpms net> wrote: > > Nope, those packages are already all made for "development" > > So that the fc4 label in binary rpms name: > gstreamer-plugins-bad-0.10.0.1-1.2.fc4.1.i386.rpm > is ininfluent and one can install on rawhide as is? It's not "fc4", it's "fc4.1" so that the main part of the release doesn't need to be bumped once the final rebuild with "fc5" will happen ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.15-1.1830_FC4 Load : 0.34 0.41 0.29 From buildsys at redhat.com Fri Feb 10 12:57:44 2006 From: buildsys at redhat.com (Build System) Date: Fri, 10 Feb 2006 07:57:44 -0500 Subject: rawhide report: 20060210 changes (part 1/2) Message-ID: <200602101257.k1ACviK4014258@porkchop.devel.redhat.com> New package libvirt Library providing an API to use the Xen virtualization Updated Packages: MySQL-python-1.2.0-3.2 ---------------------- * Tue Feb 07 2006 Jesse Keating - 1.2.0-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes NetworkManager-0.5.1-10.cvs20060205.1 ------------------------------------- * Tue Feb 07 2006 Jesse Keating - 0.5.1-10.cvs20060205.1 - rebuilt for new gcc4.1 snapshot and glibc changes ORBit-1:0.5.17-15.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 1:0.5.17-15.2 - rebuilt for new gcc4.1 snapshot and glibc changes OpenIPMI-1.4.14-18.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 1.4.14-18.1 - rebuilt for new gcc4.1 snapshot and glibc changes PyQt-3.15-1.2 ------------- * Tue Feb 07 2006 Jesse Keating - 3.15-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes PyXML-0.8.4-3.2 --------------- * Tue Feb 07 2006 Jesse Keating - 0.8.4-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes SDL-1.2.9-5.1 ------------- * Tue Feb 07 2006 Jesse Keating - 1.2.9-5.1 - rebuilt for new gcc4.1 snapshot and glibc changes SysVinit-2.86-2.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 2.86-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes Xaw3d-1.5E-6.2 -------------- * Tue Feb 07 2006 Jesse Keating - 1.5E-6.2 - rebuilt for new gcc4.1 snapshot and glibc changes am-utils-5:6.1.3-1.2 -------------------- * Tue Feb 07 2006 Jesse Keating - 5:6.1.3-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes anaconda-10.91.19-1 ------------------- * Thu Feb 09 2006 Chris Lumens 10.91.19-1 - Fix loader typo. * Thu Feb 09 2006 Chris Lumens 10.91.18-1 - Add iscsi support (Patrick Mansfield ) - Allow retry if CD image isn't found on NFS server (#109051, dcantrel) - Fix location of video modes data files - Add x86_64 kernel-xen-guest (katzj) - Better loader debugging support (katzj) aspell-ga-50:0.50-4.2 --------------------- * Tue Feb 07 2006 Jesse Keating - 50:0.50-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes aspell-hr-50:0.51-4.2 --------------------- * Tue Feb 07 2006 Jesse Keating - 50:0.51-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes aspell-is-50:0.51.1-2.2 ----------------------- * Tue Feb 07 2006 Jesse Keating - 50:0.51.1-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes attr-2.4.28-1.1 --------------- * Tue Feb 07 2006 Jesse Keating - 2.4.28-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes audit-1.1.4-3 ------------- * Thu Feb 09 2006 Steve Grubb 1.1.4-3 - Change audit_log_semanage_message to take new params. bg5ps-1.3.0-22.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 1.3.0-22.2 - rebuilt for new gcc4.1 snapshot and glibc changes cairo-1.0.2-4.1 --------------- * Tue Feb 07 2006 Jesse Keating - 1.0.2-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes dbus-0.60-7.1 ------------- * Tue Feb 07 2006 Jesse Keating - 0.60-7.1 - rebuilt for new gcc4.1 snapshot and glibc changes ddd-3.3.11-5.1 -------------- * Tue Feb 07 2006 Jesse Keating - 3.3.11-5.1 - rebuilt for new gcc4.1 snapshot and glibc changes dovecot-1.0-0.beta2.4 --------------------- * Thu Feb 09 2006 Petr Rockai - 1.0-0.beta2.4 - enable inotify as it should work now (#179431) eclipse-1:3.1.2-1jpp_5fc ------------------------ * Tue Feb 07 2006 Andrew Overholt 3.1.2-1jpp_5fc - Use new java-1.4.2-gcj-compat-javadoc package. - Always generate debug info when building RPMs (Andrew Haley). - Slightly modify swt-gtk symlinks (rh#180000). eclipse-bugzilla-1:0.1.1_fc-6.2 ------------------------------- * Thu Feb 09 2006 Andrew Overholt 0.1.1_fc-6.2 - Build against 3.1.2. * Tue Feb 07 2006 Jesse Keating - 1:0.1.1_fc-6.1 - rebuilt for new gcc4.1 snapshot and glibc changes eclipse-cdt-1:3.0.1-1jpp_6fc ---------------------------- * Thu Feb 09 2006 Andrew Overholt 3.0.1-1jpp_6fc - Make it Require >= 3.1.2. * Thu Feb 09 2006 Andrew Overholt 3.0.1-1jpp_5fc - Build against SDK 3.1.2. * Tue Feb 07 2006 Jesse Keating - 1:3.0.1-1jpp_5fc - rebuilt for new gcc4.1 snapshot and glibc changes eclipse-changelog-1:2.0.1_fc-24 ------------------------------- * Thu Feb 09 2006 Andrew Overholt 2.0.1_fc-24 - Build against 3.1.2. eclipse-pydev-1:0.9.3_fc-14 --------------------------- * Thu Feb 09 2006 Andrew Overholt 0.9.3_fc-14 - Build against 3.1.2. ekiga-1.99.0-3.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 1.99.0-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes evolution-2.5.90-2 ------------------ * Thu Feb 09 2006 Christopher Aillon - 2.5.90-2 - Disable the inline audio plugin for now since it uses gstreamer08 * Tue Feb 07 2006 Jesse Keating - 2.5.90-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Mon Jan 30 2006 David Malcolm - 2.5.90-1 - 2.5.90 - trimmed patches 805 and 808, as parts of these got merged upstream - trimmed and regenerated patch 806 to track upstream - removed the mail-to-task plugin XML UI file frysk-0.0.1.2006.02.09-0.FC5.0 ------------------------------ * Thu Feb 09 2006 Adam Jocksch 0.0.1.2006.02.09-0.FC5.0 - Removed ftrace from %files and added libexedir files and man pages. - Imported new frysk tarball, gdm-1:2.13.0.7-2 ---------------- * Thu Feb 09 2006 Matthias Clasen - 2.13.0.7-2 - Make gdmsetup use consolehelper - Don't use deprecated pam_stack gnome-icon-theme-2.13.7-4 ------------------------- * Thu Feb 09 2006 Matthias Clasen 2.13.7-4 - Add better shutdown icon * Thu Feb 09 2006 Matthias Clasen 2.13.7-3 - Add the spinner back gnome-mag-0.12.3-2 ------------------ * Thu Feb 09 2006 Matthias Clasen - 0.12.3-2 - Make it build * Tue Feb 07 2006 Jesse Keating - 0.12.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes gnome-themes-2.13.90-3 ---------------------- * Thu Feb 09 2006 Matthias Clasen - 2.13.90-3 - Fix a warning htdig-3:3.2.0b6-6.4.2 --------------------- * Thu Feb 09 2006 Jitka Kudrnacova - 3:3.2.0b6-6.4.2 - fixed building in rawhide (#176894) * Tue Feb 07 2006 Jesse Keating - 3:3.2.0b6-6.4.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 09 2005 Jesse Keating - rebuilt - patched to not fail on apache version 2.x kernel-2.6.15-1.1928_FC5 ------------------------ * Thu Feb 09 2006 Dave Jones - 2.6.16rc2-git7 - More airo encryption fixing from Dan Williams. - Minor tweaks to the oops-pauser. - Disable DRM for certain Radeons that don't work right now. - Further fixing of the selinux mprotect patch * Wed Feb 08 2006 Dave Jones - 2.6.16rc2-git6 libXScrnSaver-1.0.1-1.1 ----------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXTrap-1.0.0-2.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 1.0.0-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXcursor-1.1.5.2-2.1 ---------------------- * Tue Feb 07 2006 Jesse Keating - 1.1.5.2-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXevie-1.0.0-2.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 1.0.0-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXfont-1.0.0-2.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 1.0.0-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXfontcache-1.0.1-1.1 ----------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXft-2.1.8.2-3.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 2.1.8.2-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXi-1.0.0-2.1 --------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Mon Jan 23 2006 Mike A. Harris 1.0.0-2 - Bumped and rebuilt * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libXi to version 1.0.0 from X11R7 RC4 libXinerama-1.0.1-1.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXmu-1.0.0-2.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXp-1.0.0-2.1 --------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXpm-3.5.4.2-2.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 3.5.4.2-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXrandr-1.1.0.2-2.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 1.1.0.2-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXrender-0.9.0.2-3.1 ---------------------- * Tue Feb 07 2006 Jesse Keating - 0.9.0.2-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXres-1.0.0-2.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXt-1.0.0-2.1 --------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Mon Jan 23 2006 Mike A. Harris 1.0.0-2 - Bumped and rebuilt * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libXt to version 1.0.0 from X11R7 RC4 - Added makestrs and it's manpage to the devel subpackage. libXtst-1.0.1-1.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXv-1.0.1-1.1 --------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXvMC-1.0.1-2.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXxf86dga-1.0.0-2.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXxf86misc-1.0.0-2.1 ---------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libXxf86vm-1.0.0-2.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes libgnome-2.13.7-5 ----------------- * Thu Feb 09 2006 Matthias Clasen - 2.13.7-5 - Rebuild * Tue Feb 07 2006 Jesse Keating - 2.13.7-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Sun Feb 05 2006 Matthias Clasen 2.13.7-4 - Update requires libgssapi-0.7-2 --------------- libpfm-3.0-5 ------------ * Thu Feb 09 2006 Florian La Roche - remove empty scripts libunwind-0.98.2-4 ------------------ * Thu Feb 09 2006 Florian La Roche - remove empty scripts libxkbfile-1.0.1-1.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes libxkbui-1.0.1-1.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes libxklavier-2.1-3.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 2.1-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes libxml-1:1.8.17-13.2 -------------------- * Tue Feb 07 2006 Jesse Keating - 1:1.8.17-13.2 - rebuilt for new gcc4.1 snapshot and glibc changes libxml2-2.6.23-1.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 2.6.23-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes libxslt-1.1.15-1.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 1.1.15-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes linux-atm-2.5.0-0.20050118.3.1 ------------------------------ * Tue Feb 07 2006 Jesse Keating - 2.5.0-0.20050118.3.1 - rebuilt for new gcc4.1 snapshot and glibc changes linuxdoc-tools-0.9.21-6.2 ------------------------- * Tue Feb 07 2006 Jesse Keating - 0.9.21-6.2 - rebuilt for new gcc4.1 snapshot and glibc changes linuxwacom-0:0.7.2-1.1 ---------------------- * Tue Feb 07 2006 Jesse Keating - 0:0.7.2-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes lksctp-tools-1.0.5-1.fc5.1 -------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.5-1.fc5.1 - rebuilt for new gcc4.1 snapshot and glibc changes lockdev-1.0.1-9.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1-9.2 - rebuilt for new gcc4.1 snapshot and glibc changes logrotate-3.7.3-2.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 3.7.3-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes lrzsz-0.12.20-21.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 0.12.20-21.2 - rebuilt for new gcc4.1 snapshot and glibc changes lslk-1.29-16.2 -------------- * Tue Feb 07 2006 Jesse Keating - 1.29-16.2 - rebuilt for new gcc4.1 snapshot and glibc changes lsof-4.76-1.2 ------------- * Tue Feb 07 2006 Jesse Keating - 4.76-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes ltrace-0.3.36-4.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 0.3.36-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes lv-4.51-7.2 ----------- * Tue Feb 07 2006 Jesse Keating - 4.51-7.2 - rebuilt for new gcc4.1 snapshot and glibc changes lvm2-2.02.01-1.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 2.02.01-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes lynx-2.8.5-27.2 --------------- * Tue Feb 07 2006 Jesse Keating - 2.8.5-27.2 - rebuilt for new gcc4.1 snapshot and glibc changes m17n-db-1.3.2-1 --------------- * Fri Feb 10 2006 Jens Petersen - 1.3.2-1 - update to 1.3.2 bugfix release - do not include ja-anthy.mim input map m17n-lib-1.3.2-1 ---------------- * Fri Feb 10 2006 Jens Petersen - 1.3.2-1 - update to 1.3.2 release - m17n-lib-no-gui-headers.patch is now upstream * Tue Feb 07 2006 Jesse Keating - 1.3.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes m2crypto-0.15-3.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 0.15-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes m4-1.4.4-1.2 ------------ * Tue Feb 07 2006 Jesse Keating - 1.4.4-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes macutils-2.0b3-32.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 2.0b3-32.2 - rebuilt for new gcc4.1 snapshot and glibc changes magma-1.0.3-3.2 --------------- * Tue Feb 07 2006 Jesse Keating - 1.0.3-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 09 2005 Jesse Keating - rebuilt * Tue Nov 15 2005 Chris Feist - used new upstream source to fix dep/soname issues. mailman-3:2.1.7-1.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 3:2.1.7-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes mailx-8.1.1-44.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 8.1.1-44.2 - rebuilt for new gcc4.1 snapshot and glibc changes make-1:3.80-10.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 1:3.80-10.1 - rebuilt for new gcc4.1 snapshot and glibc changes man-1.6c-1.1 ------------ * Tue Feb 07 2006 Jesse Keating - 1.6c-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Thu Feb 02 2006 Florian La Roche - 1.6c * Tue Dec 13 2005 Ivana Varekova 1.6b-2 - makewhatis change - add info about packages (bug 175595) mc-1:4.6.1a-7.1 --------------- * Tue Feb 07 2006 Jesse Keating - 1:4.6.1a-7.1 - rebuilt for new gcc4.1 snapshot and glibc changes mdadm-2.2-1.fc5.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 2.2-1.fc5.2 - rebuilt for new gcc4.1 snapshot and glibc changes metacity-2.13.55-1.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 2.13.55-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes mgetty-1.1.33-7.FC5.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 1.1.33-7.FC5.1 - rebuilt for new gcc4.1 snapshot and glibc changes mikmod-3.1.6-36.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 3.1.6-36.2 - rebuilt for new gcc4.1 snapshot and glibc changes mingetty-1.07-5.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 1.07-5.2 - rebuilt for new gcc4.1 snapshot and glibc changes minicom-2.1-1.2 --------------- * Tue Feb 07 2006 Jesse Keating - 2.1-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes mktemp-3:1.5-23.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 3:1.5-23.2 - rebuilt for new gcc4.1 snapshot and glibc changes mlocate-0.12-1.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 0.12-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes mod_auth_kerb-5.0-8.2 --------------------- * Tue Feb 07 2006 Jesse Keating - 5.0-8.2 - rebuilt for new gcc4.1 snapshot and glibc changes mod_auth_mysql-1:3.0.0-2.2 -------------------------- * Tue Feb 07 2006 Jesse Keating - 1:3.0.0-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes mod_auth_pgsql-2.0.3-2.1 ------------------------ * Tue Feb 07 2006 Jesse Keating - 2.0.3-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes mod_authz_ldap-0.26-6.2 ----------------------- * Tue Feb 07 2006 Jesse Keating - 0.26-6.2 - rebuilt for new gcc4.1 snapshot and glibc changes mod_perl-2.0.2-3.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 2.0.2-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes module-init-tools-3.2-0.pre9.2.1 -------------------------------- * Tue Feb 07 2006 Jesse Keating - 3.2-0.pre9.2.1 - rebuilt for new gcc4.1 snapshot and glibc changes mono-1.1.13.2-1.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 1.1.13.2-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes mozilla-37:1.7.12-4.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 37:1.7.12-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes mozplugger-1.7.3-2.2 -------------------- * Tue Feb 07 2006 Jesse Keating - 1.7.3-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes mpage-2.5.4-6 ------------- * Wed Feb 08 2006 Jitka Kudrnacova 2.5.4-6 - Fixed page scaling (bug #173276) and modified the manpage (the bug was mentioned in the manpage) * Tue Feb 07 2006 Jesse Keating - 2.5.4-5.2 - rebuilt for new gcc4.1 snapshot and glibc changes mrtg-2.13.0-1.1 --------------- * Tue Feb 07 2006 Jesse Keating - 2.13.0-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes mt-st-0.9b-2.2 -------------- * Tue Feb 07 2006 Jesse Keating - 0.9b-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes mtools-3.9.10-1.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 3.9.10-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes mtr-2:0.69-7.2 -------------- * Tue Feb 07 2006 Jesse Keating - 2:0.69-7.2 - rebuilt for new gcc4.1 snapshot and glibc changes mtx-1.2.18-8.2 -------------- * Tue Feb 07 2006 Jesse Keating - 1.2.18-8.2 - rebuilt for new gcc4.1 snapshot and glibc changes mutt-5:1.4.2.1-6.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 5:1.4.2.1-6.2 - rebuilt for new gcc4.1 snapshot and glibc changes mx-2.0.6-2.2 ------------ * Tue Feb 07 2006 Jesse Keating - 2.0.6-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 09 2005 Jesse Keating - rebuilt * Mon Mar 14 2005 Mihai Ibanescu 2.0.6-2 - Rebuilt mx4j-1:3.0.1-1jpp_8fc --------------------- * Tue Feb 07 2006 Jesse Keating - 1:3.0.1-1jpp_8fc - rebuilt for new gcc4.1 snapshot and glibc changes - remove dep on jonathan-rmi mysql-5.0.18-2 -------------- * Thu Feb 09 2006 Tom Lane 5.0.18-2 - err-log option has been renamed to log-error, fix my.cnf and initscript * Tue Feb 07 2006 Jesse Keating - 5.0.18-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Thu Jan 05 2006 Tom Lane 5.0.18-1 - Update to MySQL 5.0.18 mysql-connector-odbc-3.51.12-1.2 -------------------------------- mysqlclient10-3.23.58-9.1 ------------------------- * Tue Feb 07 2006 Jesse Keating - 3.23.58-9.1 - rebuilt for new gcc4.1 snapshot and glibc changes mysqlclient14-4.1.14-4.1 ------------------------ * Tue Feb 07 2006 Jesse Keating - 4.1.14-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes nano-1.3.8-1.2 -------------- * Tue Feb 07 2006 Jesse Keating - 1.3.8-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes nasm-0.98.39-3.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 0.98.39-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes nautilus-2.13.90-2.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 2.13.90-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Mon Feb 06 2006 Matthias Clasen - 2.13.90-2 - Avoid delays in rendering the background * Tue Jan 31 2006 Matthias Clasen - 2.13.90-1 - Update to 2.13.90 nautilus-cd-burner-2.13.90-1.1 ------------------------------ * Tue Feb 07 2006 Jesse Keating - 2.13.90-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes nautilus-sendto-0.4-7.1 ----------------------- * Tue Feb 07 2006 Jesse Keating - 0.4-7.1 - rebuilt for new gcc4.1 snapshot and glibc changes nc-1.84-3.1 ----------- * Tue Feb 07 2006 Jesse Keating - 1.84-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Wed Jan 25 2006 Radek Vokal 1.84-3 - warnings cleaned-up, compile with -Werror ncompress-4.2.4-43.2 -------------------- * Tue Feb 07 2006 Jesse Keating - 4.2.4-43.2 - rebuilt for new gcc4.1 snapshot and glibc changes ncpfs-2.2.6-1.2 --------------- * Tue Feb 07 2006 Jesse Keating - 2.2.6-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes ncurses-5.5-18.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 5.5-18.1 - rebuilt for new gcc4.1 snapshot and glibc changes neon-0.25.5-1.1 --------------- * Tue Feb 07 2006 Jesse Keating - 0.25.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes net-snmp-5.3-4.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 5.3-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes net-tools-1.60-61.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 1.60-61.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Mon Feb 06 2006 Radek Vok??l 1.60-61 - mii-tool manpage fixed (#180055) netdump-0.7.14-1.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 0.7.14-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes netpbm-10.31-2.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 10.31-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes newt-0.52.2-5.1 --------------- * Tue Feb 07 2006 Jesse Keating - 0.52.2-5.1 - rebuilt for new gcc4.1 snapshot and glibc changes newt-perl-1.08-9.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 1.08-9.2 - rebuilt for new gcc4.1 snapshot and glibc changes nfs-utils-1.0.8.rc2-4.FC5.1 --------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.8.rc2-4.FC5.1 - rebuilt for new gcc4.1 snapshot and glibc changes nfs-utils-lib-1.0.8-3 --------------------- * Thu Feb 09 2006 Florian La Roche 1.0.8-3 - remove empty scripts nhpf-1.42-9.2 ------------- * Tue Feb 07 2006 Jesse Keating - 1.42-9.2 - rebuilt for new gcc4.1 snapshot and glibc changes nkf-2.05-1.2 ------------ * Tue Feb 07 2006 Jesse Keating - 2.05-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes nmap-2:4.00-1.1 --------------- * Tue Feb 07 2006 Jesse Keating - 2:4.00-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes notify-daemon-0.3.1-7 --------------------- * Thu Feb 09 2006 Florian La Roche - remove empty scripts from .spec file * Tue Feb 07 2006 Jesse Keating - 0.3.1-6.1 - rebuilt for new gcc4.1 snapshot and glibc changes nspr-4.6.1-2.1 -------------- * Tue Feb 07 2006 Jesse Keating - 4.6.1-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes nss-3.11-3.1 ------------ * Tue Feb 07 2006 Jesse Keating - 3.11-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes nss_db-2.2-34.2 --------------- * Tue Feb 07 2006 Jesse Keating - 2.2-34.2 - rebuilt for new gcc4.1 snapshot and glibc changes nss_ldap-248-2 -------------- * Thu Feb 09 2006 Nalin Dahyabhai - 248-2 - set "nss_initgroups_ignoreusers root,ldap" in the default configuration file, so that nss_ldap will assume that there are no supplemental groups for this user to be found in the directory server (#180657) * Tue Feb 07 2006 Jesse Keating - 248-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes ntp-4.2.0.a.20050816-10.2 ------------------------- * Tue Feb 07 2006 Jesse Keating - 4.2.0.a.20050816-10.2 - rebuilt for new gcc4.1 snapshot and glibc changes numactl-0.6.4-1.25.1 -------------------- * Tue Feb 07 2006 Jesse Keating - error: line 4: Tag takes single token only: Release: :.1 1.24.1 - rebuilt for new gcc4.1 snapshot and glibc changes nut-2.0.2-6.1 ------------- * Tue Feb 07 2006 Jesse Keating - 2.0.2-6.1 - rebuilt for new gcc4.1 snapshot and glibc changes oaf-0.6.10-12.2 --------------- * Tue Feb 07 2006 Jesse Keating - 0.6.10-12.2 - rebuilt for new gcc4.1 snapshot and glibc changes opal-2.1-1.1 ------------ open-1.4-24.2 ------------- * Tue Feb 07 2006 Jesse Keating - 1.4-24.2 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 09 2005 Jesse Keating - rebuilt * Sat Mar 05 2005 Than Ngo 1.4-24 - rebuilt openhpi-2.2.1-4.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 2.2.1-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes openjade-1.3.2-23.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 1.3.2-23.1 - rebuilt for new gcc4.1 snapshot and glibc changes openldap-2.3.19-3 ----------------- * Thu Feb 09 2006 Jay Fenlason 2.3.19-3 - Modify the ldap.init script to call runuser correctly. * Tue Feb 07 2006 Jesse Keating - 2.3.19-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes openmotif-2.3.0-0.1.9.1 ----------------------- * Tue Feb 07 2006 Jesse Keating - 2.3.0-0.1.9.1 - rebuilt for new gcc4.1 snapshot and glibc changes openobex-1.0.1-4.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 1.0.1-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes openobex-apps-1.0.0-8.2 ----------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0-8.2 - rebuilt for new gcc4.1 snapshot and glibc changes openoffice.org-1:2.0.1.1-11.2.1 ------------------------------- * Tue Feb 07 2006 Jesse Keating - 1:2.0.1.1-11.2.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Mon Feb 06 2006 Caolan McNamara - 1:2.0.1.1-11 - rh#180125# unnecessary gnome mime files opensm-1.0-0.4265.1.FC5.2 ------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0-0.4265.1.FC5.2 - rebuilt for new gcc4.1 snapshot and glibc changes opensp-1.5.2-1.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 1.5.2-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes openssl-0.9.8a-5.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 0.9.8a-5.1 - rebuilt for new gcc4.1 snapshot and glibc changes openssl097a-0.9.7a-4.2 ---------------------- * Tue Feb 07 2006 Jesse Keating - 0.9.7a-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes openswan-2.4.4-1.1.2 -------------------- * Tue Feb 07 2006 Jesse Keating - 2.4.4-1.1.2 - rebuilt for new gcc4.1 snapshot and glibc changes oprofile-0.9.1-7.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 0.9.1-7.1 - rebuilt for new gcc4.1 snapshot and glibc changes pam-0.99.3.0-1.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 0.99.3.0-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Feb 03 2006 Tomas Mraz 0.99.3.0-1 - new upstream version - updated db4 to 4.3.29 - added module pam_tally2 with auditing support - added manual pages for system-auth and config-util (#179584) * Tue Jan 03 2006 Tomas Mraz 0.99.2.1-3 - remove 'initscripts' dependency (#176508) - update pam-redhat modules, merged patches pam_ccreds-3-3.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 3-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes pam_passwdqc-1.0.2-1.2 ---------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.2-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes pam_smb-1.1.7-7.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 1.1.7-7.1 - rebuilt for new gcc4.1 snapshot and glibc changes pango-1.11.4-1.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 1.11.4-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes parted-1.6.25-6 --------------- * Tue Feb 07 2006 Peter Jones 1.6.25-6 - Fix dm partition naming. * Tue Feb 07 2006 Jesse Keating 1.6.25-5.2 - rebuilt for new gcc4.1 snapshot and glibc changes passwd-0.71-3.1 --------------- * Tue Feb 07 2006 Jesse Keating - 0.71-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes patch-2.5.4-29.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 2.5.4-29.2 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 09 2005 Jesse Keating - rebuilt * Thu Sep 08 2005 Tim Waugh 2.5.4-29 - Remove SELinux patch for now (bug #167822). pax-3.4-1.2 ----------- * Tue Feb 07 2006 Jesse Keating - 3.4-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes pciutils-2.2.1-1.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 2.2.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes pcmciautils-011-1.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 011-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes pcre-6.3-1.2 ------------ * Tue Feb 07 2006 Jesse Keating - 6.3-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes perl-BSD-Resource-1.24-3.2.1 ---------------------------- * Tue Feb 07 2006 Jesse Keating - 1.24-3.2.1 - rebuilt for new gcc4.1 snapshot and glibc changes perl-Bit-Vector-6.4-2.2.1 ------------------------- * Tue Feb 07 2006 Jesse Keating - 6.4-2.2.1 - rebuilt for new gcc4.1 snapshot and glibc changes perl-Compress-Zlib-1.41-1.2.1 ----------------------------- * Tue Feb 07 2006 Jesse Keating - 1.41-1.2.1 - rebuilt for new gcc4.1 snapshot and glibc changes perl-Crypt-SSLeay-0.51-9.2.1 ---------------------------- * Tue Feb 07 2006 Jesse Keating - 0.51-9.2.1 - rebuilt for new gcc4.1 snapshot and glibc changes perl-DBD-MySQL-3.0002-2.2.1 --------------------------- * Tue Feb 07 2006 Jesse Keating - 3.0002-2.2.1 - rebuilt for new gcc4.1 snapshot and glibc changes perl-DBD-Pg-1.43-2.2.1 ---------------------- * Tue Feb 07 2006 Jesse Keating - 1.43-2.2.1 - rebuilt for new gcc4.1 snapshot and glibc changes perl-DBI-1.50-2.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 1.50-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes perl-Digest-SHA1-2.11-1.1 ------------------------- * Tue Feb 07 2006 Jesse Keating - 2.11-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes perl-HTML-Parser-3.48-1.1.1 --------------------------- * Tue Feb 07 2006 Jesse Keating - 3.48-1.1.1 - rebuilt for new gcc4.1 snapshot and glibc changes perl-Net-DNS-0.55-1.1.1 ----------------------- * Tue Feb 07 2006 Jesse Keating - 0.55-1.1.1 - rebuilt for new gcc4.1 snapshot and glibc changes perl-PDL-2.4.2-2.fc5.1.2.1 -------------------------- * Tue Feb 07 2006 Jesse Keating - 2.4.2-2.fc5.1.2.1 - rebuilt for new gcc4.1 snapshot and glibc changes perl-String-CRC32-1.3-3.FC5.1 ----------------------------- * Tue Feb 07 2006 Jesse Keating - 1.3-3.FC5.1 - rebuilt for new gcc4.1 snapshot and glibc changes perl-TermReadKey-2.30-1.2.1 --------------------------- * Tue Feb 07 2006 Jesse Keating - 2.30-1.2.1 - rebuilt for new gcc4.1 snapshot and glibc changes perl-XML-LibXML-1.58-2.2.1 -------------------------- * Tue Feb 07 2006 Jesse Keating - 1.58-2.2.1 - rebuilt for new gcc4.1 snapshot and glibc changes perl-XML-Parser-2.34-6.1.2.1 ---------------------------- * Tue Feb 07 2006 Jesse Keating - 2.34-6.1.2.1 - rebuilt for new gcc4.1 snapshot and glibc changes pfmon-3.0-7 ----------- * Thu Feb 09 2006 Florian La Roche - remove empty scripts * Tue Feb 07 2006 Jesse Keating - 3.0-6.2 - rebuilt for new gcc4.1 snapshot and glibc changes php-5.1.2-4.1 ------------- * Tue Feb 07 2006 Jesse Keating - 5.1.2-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes pilot-link-1:0.12.0-0.pre4.5.2 ------------------------------ * Tue Feb 07 2006 Jesse Keating - 1:0.12.0-0.pre4.5.2 - rebuilt for new gcc4.1 snapshot and glibc changes pinfo-0.6.8-11.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 0.6.8-11.2 - rebuilt for new gcc4.1 snapshot and glibc changes pkgconfig-1:0.20-2.2 -------------------- * Tue Feb 07 2006 Jesse Keating - 1:0.20-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes planner-0.13-4 -------------- * Thu Feb 09 2006 Caolan McNamara - 0.13-4 - rebuild * Tue Feb 07 2006 Jesse Keating - 0.13-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes pm-utils-0.09-1.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 0.09-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes pnm2ppa-1:1.04-13.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 1:1.04-13.2 - rebuilt for new gcc4.1 snapshot and glibc changes poppler-0.5.0-4.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 0.5.0-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes portmap-4.0-65.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 4.0-65.2 - rebuilt for new gcc4.1 snapshot and glibc changes postfix-2:2.2.8-1.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 2:2.2.8-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes postgresql-8.1.2-1.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 8.1.2-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes postgresql-odbc-08.01.0200-1.1 ------------------------------ * Tue Feb 07 2006 Jesse Keating - 08.01.0200-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes ppc64-utils-0.9-12.2 -------------------- * Tue Feb 07 2006 Jesse Keating - 0.9-12.2 - rebuilt for new gcc4.1 snapshot and glibc changes ppp-2.4.3-6.2 ------------- * Tue Feb 07 2006 Jesse Keating - 2.4.3-6.2 - rebuilt for new gcc4.1 snapshot and glibc changes prctl-1.4-5.2 ------------- * Tue Feb 07 2006 Jesse Keating - 1.4-5.2 - rebuilt for new gcc4.1 snapshot and glibc changes privoxy-3.0.3-9.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 3.0.3-9.2 - rebuilt for new gcc4.1 snapshot and glibc changes procinfo-18-18.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 18-18.2 - rebuilt for new gcc4.1 snapshot and glibc changes procmail-3.22-16.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 3.22-16.2 - rebuilt for new gcc4.1 snapshot and glibc changes procps-3.2.6-3.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 3.2.6-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes psacct-6.3.2-38.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 6.3.2-38.1 - rebuilt for new gcc4.1 snapshot and glibc changes psmisc-21.8-1.2 --------------- * Tue Feb 07 2006 Jesse Keating - 21.8-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes pstack-1.2-7.2 -------------- * Tue Feb 07 2006 Jesse Keating - 1.2-7.2 - rebuilt for new gcc4.1 snapshot and glibc changes psutils-1.17-25.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 1.17-25.2 - rebuilt for new gcc4.1 snapshot and glibc changes pump-0.8.24-1.2 --------------- * Tue Feb 07 2006 Jesse Keating - 0.8.24-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes pwlib-1.9.2-1.1 --------------- * Tue Feb 07 2006 Jesse Keating - 1.9.2-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes pyOpenSSL-0.6-1.p24.7.2 ----------------------- * Tue Feb 07 2006 Jesse Keating - 0.6-1.p24.7.2 - rebuilt for new gcc4.1 snapshot and glibc changes pycairo-1.0.2-1.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 1.0.2-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes pygtk2-2.8.4-1.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 2.8.4-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes pykickstart-0.18-1 ------------------ * Thu Feb 09 2006 Chris Lumens 0.18-1 - Fix some errors pychecker caught. - Allow exceptions to not be fatal so ksvalidator can spot more errors in a single pass (#179894). pyorbit-2.0.1-4.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 2.0.1-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes pyparted-1.6.10-1.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 1.6.10-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes python-2.4.2-3.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 2.4.2-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes python-elementtree-1.2.6-4.2 ---------------------------- * Tue Feb 07 2006 Jesse Keating - 1.2.6-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes python-ldap-0:2.0.6-5.2 ----------------------- * Tue Feb 07 2006 Jesse Keating - 0:2.0.6-5.2 - rebuilt for new gcc4.1 snapshot and glibc changes python-numeric-23.7-2.2 ----------------------- * Tue Feb 07 2006 Jesse Keating - 23.7-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes From buildsys at redhat.com Fri Feb 10 12:57:57 2006 From: buildsys at redhat.com (Build System) Date: Fri, 10 Feb 2006 07:57:57 -0500 Subject: rawhide report: 20060210 changes (part 2/2) Message-ID: <200602101257.k1ACvvFK014297@porkchop.devel.redhat.com> python-sqlite-1.1.7-1.1 ----------------------- * Tue Feb 07 2006 Jesse Keating - 1.1.7-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Feb 03 2006 Paul Nasrat - 1.1.7-1 - Upgrade to latest upstream 1.1.x series - sqlite_prepare fix now upstream - Update url information qt-1:3.3.5-12.1 --------------- * Tue Feb 07 2006 Jesse Keating - 1:3.3.5-12.1 - rebuilt for new gcc4.1 snapshot and glibc changes quagga-0:0.98.5-3.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 0:0.98.5-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes quota-1:3.13-1.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 1:3.13-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes rarpd-ss981107-22.2 ------------------- * Tue Feb 07 2006 Jesse Keating - ss981107-22.2 - rebuilt for new gcc4.1 snapshot and glibc changes rcs-5.7-29.2 ------------ * Tue Feb 07 2006 Jesse Keating - 5.7-29.2 - rebuilt for new gcc4.1 snapshot and glibc changes rdate-1.4-4.2 ------------- * Tue Feb 07 2006 Jesse Keating - 1.4-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes rdesktop-1.4.1-3.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 1.4.1-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes rdist-1:6.1.5-42.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 1:6.1.5-42.2 - rebuilt for new gcc4.1 snapshot and glibc changes readahead-1:1.2-1.24.1 ---------------------- * Tue Feb 07 2006 Jesse Keating - error: line 4: Tag takes single token only: Release: :.1 1.23.1 - rebuilt for new gcc4.1 snapshot and glibc changes readline-5.0-3.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 5.0-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes redhat-artwork-0.238-1 ---------------------- * Thu Feb 09 2006 Matthias Clasen 0.238-1 - Add left-handed cursor themes * Tue Feb 07 2006 Jesse Keating - 0.237-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes redhat-lsb-3.0-9.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 3.0-9.1 - rebuilt for new gcc4.1 snapshot and glibc changes regexp-0:1.3-2jpp_5fc --------------------- * Tue Feb 07 2006 Jesse Keating - 0:1.3-2jpp_5fc - rebuilt for new gcc4.1 snapshot and glibc changes reiserfs-utils-2:3.6.19-2.2 --------------------------- * Tue Feb 07 2006 Jesse Keating - 2:3.6.19-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes rhdb-utils-8.1.1-1.2 -------------------- * Tue Feb 07 2006 Jesse Keating - 8.1.1-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes rhgb-0.16.2-21.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 0.16.2-21.1 - rebuilt for new gcc4.1 snapshot and glibc changes rhn-applet-2.1.17-4.2 --------------------- * Tue Feb 07 2006 Jesse Keating - 2.1.17-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes rhpl-0.181-2 ------------ * Thu Feb 09 2006 Jeremy Katz - 0.181-2 - rebuild rhythmbox-0.9.3.1-1.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 0.9.3.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes rp-pppoe-3.5-30.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 3.5-30.2 - rebuilt for new gcc4.1 snapshot and glibc changes rpm-4.4.2-15.1 -------------- * Tue Feb 07 2006 Jesse Keating - 4.4.2-15.1 - rebuilt for new gcc4.1 snapshot and glibc changes rsh-0.17-34 ----------- * Thu Feb 09 2006 Karel Zak 0.17-34 - fix #178916 - Line feeds when password needs changing with rlogin * Tue Feb 07 2006 Jesse Keating 0.17-33.2 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 09 2005 Jesse Keating 0.17-33.1 - rebuilt rsync-2.6.6-2.2 --------------- * Tue Feb 07 2006 Jesse Keating - 2.6.6-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes ruby-1.8.4-3.1 -------------- * Tue Feb 07 2006 Jesse Keating - 1.8.4-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes rusers-0.17-45.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 0.17-45.2 - rebuilt for new gcc4.1 snapshot and glibc changes rwall-0.17-25.2 --------------- * Tue Feb 07 2006 Jesse Keating - 0.17-25.2 - rebuilt for new gcc4.1 snapshot and glibc changes rwho-0.17-25.2 -------------- * Tue Feb 07 2006 Jesse Keating - 0.17-25.2 - rebuilt for new gcc4.1 snapshot and glibc changes sane-backends-1.0.17-3.1 ------------------------ * Tue Feb 07 2006 Jesse Keating - 1.0.17-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes sane-frontends-1.0.14-1.2 ------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.14-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes scim-1.4.4-4 ------------ * Fri Feb 10 2006 Jens Petersen - 1.4.4-4 - parse the libstdc++so7 datestamp from the wrapper script * Thu Feb 09 2006 Jens Petersen - 1.4.4-3 - build conditionally with libstdc++so7 preview to workround libstdc++ weak symbol version conflicts for c++ gtk apps built with older gcc (Benjamin Kosnik, #166041) - add with_libstdc_preview switch and tweak libtool to link against newer lib - do not change scim_binary_version in scim.pc-versioned-moduledir-179706.patch - set qtimm to xim for now * Fri Feb 03 2006 Jens Petersen - 1.4.4-2 - remove scim-reload-engines-165655.patch since it seems to break input after reloading configuration (#179807) - add gtkimm-clear-preedit-on-reset-174143.patch to clear the preedit buffer when IME turned off (Qian Shen, #174143) - add rawcode-unicode-maxlength.patch to improve input of unicode codes (James Su, #173102) - add scim.pc-versioned-moduledir-179706.patch to include api version in moduledir in scim.pc so that IMEs get installed in versioned dir by default (Akira Tagoh, #179706) scim-anthy-0.9.0-2.fc5 ---------------------- * Thu Feb 09 2006 Jens Petersen - 0.9.0-2 - build conditionally against libstdc++so7 preview library (#166041) - add with_libstdc_preview switch and tweak libtool to link against newer lib - add scim-anthy-helper-moduledir.patch to tweak the helper module install dir, since scim.pc now returns moduledir with api-version - remove anthy-imengine-helper.la scim-chewing-0.2.1-5 -------------------- * Thu Feb 09 2006 Jens Petersen - 0.2.1-5 - build conditionally against libstdc++so7 preview library (#166041) - add with_libstdc_preview switch and tweak libtool to link against newer lib - update filelist since module dir is now in api-versioned scim-hangul-0.2.1-3.fc5 ----------------------- * Thu Feb 09 2006 Jens Petersen - 0.2.1-3 - build conditionally with libstdc++so7 preview library (#166041) - add with_libstdc_preview switch and tweak libtool to link against newer lib - update filelist since moduledir is now api-versioned scim-m17n-0.1.4-3 ----------------- * Thu Feb 09 2006 Jens Petersen - 0.1.4-3 - build conditionally with libstdc++so7 preview library (#166041) - add with_libstdc_preview switch and tweak libtool to link against newer lib - specify filelist more precisely scim-pinyin-0.5.91-4 -------------------- * Thu Feb 09 2006 Jens Petersen - 0.5.91-4 - build conditionally with libstdc++so7 preview library (#166041) - add with_libstdc_preview switch and tweak libtool to link against it - update filelist since moduledir is now api-versioned scim-tables-0.5.6-2 ------------------- * Thu Feb 09 2006 Jens Petersen - 0.5.6-2 - build conditionally with libstdc++so7 preview library (#166041) - add with_libstdc_preview switch and tweak libtool to link against it - update filelist since moduledir is now api-versioned screen-4.0.2-11.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 4.0.2-11.1 - rebuilt for new gcc4.1 snapshot and glibc changes scrollkeeper-0.3.14-5.2 ----------------------- * Tue Feb 07 2006 Jesse Keating - 0.3.14-5.2 - rebuilt for new gcc4.1 snapshot and glibc changes sed-4.1.5-1.1 ------------- * Tue Feb 07 2006 Jesse Keating - 4.1.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes selinux-policy-2.2.12-1 ----------------------- * Tue Feb 07 2006 Dan Walsh 2.2.12-1 - Update from upstream sendmail-8.13.5-2.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 8.13.5-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes setarch-1.8-1.2 --------------- * Tue Feb 07 2006 Jesse Keating - 1.8-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes setools-2.3-1.1 --------------- * Tue Feb 07 2006 Jesse Keating - 2.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes setserial-2.17-19.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 2.17-19.2 - rebuilt for new gcc4.1 snapshot and glibc changes setuptool-1.18.1-1.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 1.18.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes shadow-utils-2:4.0.14-1.1 ------------------------- * Tue Feb 07 2006 Jesse Keating - 2:4.0.14-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes shared-mime-info-0.16.cvs20051219-2.1 ------------------------------------- * Tue Feb 07 2006 Jesse Keating - 0.16.cvs20051219-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes sharutils-4.6.1-1.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 4.6.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes sip-4.3.1-1.2 ------------- * Tue Feb 07 2006 Jesse Keating - 4.3.1-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes slang-2.0.5-5.2 --------------- * Tue Feb 07 2006 Jesse Keating - 2.0.5-5.2 - rebuilt for new gcc4.1 snapshot and glibc changes slrn-0.9.8.1pl1-1.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 0.9.8.1pl1-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes smartmontools-1:5.33-4.1 ------------------------ * Tue Feb 07 2006 Jesse Keating - 1:5.33-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes sound-juicer-2.13.4-3.1 ----------------------- * Tue Feb 07 2006 Jesse Keating - 2.13.4-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes sox-12.17.9-1.1 --------------- * Tue Feb 07 2006 Jesse Keating - 12.17.9-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes spamassassin-3.1.0-5.fc5.1 -------------------------- * Tue Feb 07 2006 Jesse Keating - 3.1.0-5.fc5.1 - rebuilt for new gcc4.1 snapshot and glibc changes speex-1.0.5-1.2 --------------- * Tue Feb 07 2006 Jesse Keating - 1.0.5-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes sqlite-3.3.3-1.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 3.3.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes squashfs-tools-2.2r2-2.2 ------------------------ squid-7:2.5.STABLE12-4.1 ------------------------ * Tue Feb 07 2006 Jesse Keating - 7:2.5.STABLE12-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes star-1.5a69-1.2 --------------- * Tue Feb 07 2006 Jesse Keating - 1.5a69-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes stardict-2.4.5-2.1 ------------------ * Tue Feb 07 2006 Jesse Keating - 2.4.5-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes startup-notification-0.8-3.2 ---------------------------- * Tue Feb 07 2006 Jesse Keating - 0.8-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes statserial-1.1-38.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 1.1-38.2 - rebuilt for new gcc4.1 snapshot and glibc changes strace-4.5.14-1.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 4.5.14-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes struts-0:1.2.4-2jpp_6fc ----------------------- * Tue Feb 07 2006 Jesse Keating - 0:1.2.4-2jpp_6fc - rebuilt for new gcc4.1 snapshot and glibc changes stunnel-4.14-3.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 4.14-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes subversion-1.3.0-4.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 1.3.0-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes sudo-1.6.8p12-4 --------------- * Wed Feb 08 2006 Karel Zak 1.6.8p12-4 - reset env. by default * Tue Feb 07 2006 Jesse Keating - 1.6.8p12-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes swig-1.3.24-2.2 --------------- * Tue Feb 07 2006 Jesse Keating - 1.3.24-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes symlinks-1.2-24.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 1.2-24.2 - rebuilt for new gcc4.1 snapshot and glibc changes synaptics-0:0.14.4-4.2 ---------------------- * Tue Feb 07 2006 Jesse Keating - 0:0.14.4-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes sysfsutils-1.3.0-1.2 -------------------- * Tue Feb 07 2006 Jesse Keating - 1.3.0-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes sysklogd-1.4.1-34.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 1.4.1-34.1 - rebuilt for new gcc4.1 snapshot and glibc changes sysstat-6.0.1-3.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 6.0.1-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes system-config-kickstart-2.6.6-1 ------------------------------- * Thu Feb 09 2006 Chris Lumens 2.6.6-1 - Fix .desktop file, other references to /usr/sbin. system-config-netboot-0.1.37-1 ------------------------------ * Thu Feb 09 2006 Jason Vas Dias - 0.1.37-1 - fix problem reported by f1 at micromemory.com: detect and deal with missing libraries in the client root correctly - fix bug 178392: disklessrc's "^$MODULE" should be "^$MODULE " - ship updated .po files system-config-printer-0.6.150-1.1 --------------------------------- * Tue Feb 07 2006 Jesse Keating - 0.6.150-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes systemtap-0.5.4-2.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 0.5.4-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes talk-0.17-29.2 -------------- * Tue Feb 07 2006 Jesse Keating - 0.17-29.2 - rebuilt for new gcc4.1 snapshot and glibc changes tcl-8.4.12-3.1 -------------- * Tue Feb 07 2006 Jesse Keating - 8.4.12-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes tclx-8.4.0-1.1 -------------- * Tue Feb 07 2006 Jesse Keating - 8.4.0-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes tcp_wrappers-7.6-40.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 7.6-40.1 - rebuilt for new gcc4.1 snapshot and glibc changes tcpdump-14:3.9.4-2.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 14:3.9.4-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes tcsh-6.14-5.2 ------------- * Tue Feb 07 2006 Jesse Keating - 6.14-5.2 - rebuilt for new gcc4.1 snapshot and glibc changes telnet-1:0.17-35.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 1:0.17-35.2 - rebuilt for new gcc4.1 snapshot and glibc changes tetex-3.0-16.1 -------------- * Tue Feb 07 2006 Jesse Keating - 3.0-16.1 - rebuilt for new gcc4.1 snapshot and glibc changes texinfo-4.8-9.1 --------------- * Tue Feb 07 2006 Jesse Keating - 4.8-9.1 - rebuilt for new gcc4.1 snapshot and glibc changes tftp-0.41-1.2 ------------- * Tue Feb 07 2006 Jesse Keating - 0.41-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes time-1.7-27.2 ------------- * Tue Feb 07 2006 Jesse Keating - 1.7-27.2 - rebuilt for new gcc4.1 snapshot and glibc changes timidity++-2.13.2-1.2 --------------------- * Tue Feb 07 2006 Jesse Keating - 2.13.2-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes tk-8.4.12-1.1 ------------- * Tue Feb 07 2006 Jesse Keating - 8.4.12-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes tmpwatch-2.9.6-1.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 2.9.6-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes tn5250-0.17.3-1.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 0.17.3-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes tomboy-0.3.5-1.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 0.3.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes tomcat5-0:5.0.30-8jpp_10fc -------------------------- * Tue Feb 07 2006 Jesse Keating - sh: line 1: build-classpath: command not found - rebuilt for new gcc4.1 snapshot and glibc changes totem-1.3.90-2 -------------- * Thu Feb 09 2006 Matthias Clasen - 1.3.90-2 - Rebuild * Tue Feb 07 2006 Jesse Keating - 1.3.90-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes traceroute-2:1.0.4-1.1 ---------------------- * Tue Feb 07 2006 Jesse Keating - 2:1.0.4-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes transfig-1:3.2.4-13.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 1:3.2.4-13.1 - rebuilt for new gcc4.1 snapshot and glibc changes tree-1.5.0-3.2 -------------- * Tue Feb 07 2006 Jesse Keating - 1.5.0-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes tsclient-0.140-1.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 0.140-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes ttcp-1.12-13.2 -------------- * Tue Feb 07 2006 Jesse Keating - 1.12-13.2 - rebuilt for new gcc4.1 snapshot and glibc changes ttmkfdir-3.0.9-19.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 3.0.9-19.2 - rebuilt for new gcc4.1 snapshot and glibc changes tux-3.2.18-4.2 -------------- * Tue Feb 07 2006 Jesse Keating - 3.2.18-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes tvtime-1.0.1-3.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes tzdata-2006a-2 -------------- * Thu Feb 02 2006 Petr Machata 2006a-2 - Small changes in tst-timezone.c udapl-1.2-0.4265.1.FC5.2 ------------------------ umb-scheme-3.2-39.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 3.2-39.2 - rebuilt for new gcc4.1 snapshot and glibc changes units-1.85-1.2 -------------- * Tue Feb 07 2006 Jesse Keating - 1.85-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes unix2dos-2.2-26.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 2.2-26.2 - rebuilt for new gcc4.1 snapshot and glibc changes unixODBC-2.2.11-6.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 2.2.11-6.2 - rebuilt for new gcc4.1 snapshot and glibc changes unzip-5.52-2.1 -------------- * Tue Feb 07 2006 Jesse Keating - 5.52-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes up2date-4.4.23-4.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 4.4.23-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes usbutils-0.71-1.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 0.71-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes usermode-1.85-2.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 1.85-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes utempter-0.5.5-7.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 0.5.5-7.2 - rebuilt for new gcc4.1 snapshot and glibc changes util-linux-2.13-0.15 -------------------- * Wed Feb 08 2006 Peter Jones 2.13-0.15 - add "blockdev --rmpart N " and "blockdev --rmparts " * Tue Feb 07 2006 Jesse Keating - 2.13-0.14.1 - rebuilt for new gcc4.1 snapshot and glibc changes uucp-1.07-11.2 -------------- * Tue Feb 07 2006 Jesse Keating - 1.07-11.2 - rebuilt for new gcc4.1 snapshot and glibc changes valgrind-1:3.1.0-1.1 -------------------- * Tue Feb 07 2006 Jesse Keating - 1:3.1.0-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes vconfig-1.8-7.2 --------------- * Tue Feb 07 2006 Jesse Keating - 1.8-7.2 - rebuilt for new gcc4.1 snapshot and glibc changes vim-1:6.4.006-1.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 1:6.4.006-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes vino-2.13.5-2.1 --------------- * Tue Feb 07 2006 Jesse Keating - 2.13.5-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes vlock-1.3-22.2 -------------- * Tue Feb 07 2006 Jesse Keating - 1.3-22.2 - rebuilt for new gcc4.1 snapshot and glibc changes vnc-4.1.1-35 ------------ * Wed Feb 08 2006 Jitka Kudrnacova 4.1.1-35 - Add a test for existence of index.theme before calling gtk-update-icon-cache in post-(un)installation script, bug #179704 * Tue Feb 07 2006 Jesse Keating - 4.1.1-34.1 - rebuilt for new gcc4.1 snapshot and glibc changes vorbis-tools-1:1.1.1-1.2 ------------------------ * Tue Feb 07 2006 Jesse Keating - 1:1.1.1-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes vsftpd-2.0.4-1.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 2.0.4-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes vte-0.11.17-1.fc5.1.1 --------------------- * Tue Feb 07 2006 Jesse Keating - 0.11.17-1.fc5.1.1 - rebuilt for new gcc4.1 snapshot and glibc changes w3m-0.5.1-12.2 -------------- * Tue Feb 07 2006 Jesse Keating - 0.5.1-12.2 - rebuilt for new gcc4.1 snapshot and glibc changes webalizer-2.01_10-29.2 ---------------------- * Tue Feb 07 2006 Jesse Keating - 2.01_10-29.2 - rebuilt for new gcc4.1 snapshot and glibc changes wget-1.10.2-3.2 --------------- * Tue Feb 07 2006 Jesse Keating - 1.10.2-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes which-2.16-6.2 -------------- * Tue Feb 07 2006 Jesse Keating - 2.16-6.2 - rebuilt for new gcc4.1 snapshot and glibc changes wireless-tools-1:28-0.pre10.5.2 ------------------------------- * Tue Feb 07 2006 Jesse Keating - 1:28-0.pre10.5.2 - rebuilt for new gcc4.1 snapshot and glibc changes wordtrans-1.1pre13-12.2 ----------------------- * Tue Feb 07 2006 Jesse Keating - 1.1pre13-12.2 - rebuilt for new gcc4.1 snapshot and glibc changes wpa_supplicant-0.5.1-1.1 ------------------------ * Tue Feb 07 2006 Jesse Keating - 0.5.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes wvdial-1.54.0-5.2.1 ------------------- * Tue Feb 07 2006 Jesse Keating - 1.54.0-5.2.1 - rebuilt for new gcc4.1 snapshot and glibc changes xalan-j2-0:2.6.0-3jpp_7fc ------------------------- * Tue Feb 07 2006 Jesse Keating - 0:2.6.0-3jpp_7fc - rebuilt for new gcc4.1 snapshot and glibc changes xcdroast-0.98a15-12.2 --------------------- * Tue Feb 07 2006 Jesse Keating - 0.98a15-12.2 - rebuilt for new gcc4.1 snapshot and glibc changes xchat-1:2.6.0-3.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 1:2.6.0-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes xdelta-1.1.3-17.2 ----------------- * Tue Feb 07 2006 Jesse Keating - 1.1.3-17.2 - rebuilt for new gcc4.1 snapshot and glibc changes xen-3.0.1-0.20060208.fc5.2 -------------------------- * Thu Feb 09 2006 Jeremy Katz - 3.0.1-0.20060208.fc5.2 - fix -h conflict for xenguest-isntall xerces-j2-0:2.6.2-6jpp_4fc -------------------------- * Tue Feb 07 2006 Jesse Keating - 0:2.6.2-6jpp_4fc - rebuilt for new gcc4.1 snapshot and glibc changes xferstats-2.16-13.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 2.16-13.2 - rebuilt for new gcc4.1 snapshot and glibc changes xfig-3.2.4-17.1 --------------- * Tue Feb 07 2006 Jesse Keating - 3.2.4-17.1 - rebuilt for new gcc4.1 snapshot and glibc changes xfsprogs-2.7.3-1.2 ------------------ * Tue Feb 07 2006 Jesse Keating - 2.7.3-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes xinetd-2:2.3.13-6.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 2:2.3.13-6.2 - rebuilt for new gcc4.1 snapshot and glibc changes xmlrpc-0:2.0.1-1jpp_3fc ----------------------- * Tue Feb 07 2006 Jesse Keating - 0:2.0.1-1jpp_3fc - rebuilt for new gcc4.1 snapshot and glibc changes xmlsec1-1.2.9-4.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 1.2.9-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes xmlto-0.0.18-9.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 0.0.18-9.2 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-apps-1.0.1-1.1 ----------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drivers-0.99.2-4.1 --------------------------- * Tue Feb 07 2006 Jesse Keating - 0.99.2-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-acecad-1.0.0.5-1.1 ------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-aiptek-1.0.0.5-1.1 ------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-ati-6.5.7.3-3.1 ---------------------------- * Tue Feb 07 2006 Jesse Keating - 6.5.7.3-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-calcomp-1.0.0.5-1.1 -------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-citron-2.1.1.5-1.1 ------------------------------- * Tue Feb 07 2006 Jesse Keating - 2.1.1.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-digitaledge-1.0.1.3-1.1 ------------------------------------ * Tue Feb 07 2006 Jesse Keating - 1.0.1.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-dmc-1.0.0.5-1.1 ---------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-dummy-0.1.0.5-1.1 ------------------------------ * Tue Feb 07 2006 Jesse Keating - 0.1.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-dynapro-1.0.0.5-1.1 -------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-elo2300-1.0.0.5-1.1 -------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-elographics-1.0.0.5-1.1 ------------------------------------ * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-evdev-1.0.0.5-1.1 ------------------------------ * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-fbdev-0.1.0.5-1.1 ------------------------------ * Tue Feb 07 2006 Jesse Keating - 0.1.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-fpit-1.0.0.5-1.1 ----------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-hyperpen-1.0.0.5-1.1 --------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-i810-1.4.1.3-3.1 ----------------------------- * Tue Feb 07 2006 Jesse Keating - 1.4.1.3-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-jamstudio-1.0.0.5-1.1 ---------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-joystick-1.0.0.5-1.1 --------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-keyboard-1.0.1.3-1.1 --------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-magellan-1.0.0.5-1.1 --------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-magictouch-1.0.0.5-1.1 ----------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-mga-1.2.1.3-1.1 ---------------------------- * Tue Feb 07 2006 Jesse Keating - 1.2.1.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-microtouch-1.0.0.5-1.1 ----------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-mouse-1.0.3.1-1.1 ------------------------------ * Tue Feb 07 2006 Jesse Keating - 1.0.3.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-mutouch-1.0.0.5-1.1 -------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-nv-1.0.1.5-3 ------------------------- * Thu Feb 09 2006 Mike A. Harris 1.0.1.5-3 - Added nv-1.0.1.5-updateto-cvs20050209.patch to sync driver with CVS and pick up support for newer Nvidia chips, and RandR rotation support. (#180101) * Thu Feb 09 2006 Mike A. Harris 1.0.1.5-2 - Syncronized nv.xinf with nv_driver.c PCI ID list, including 10DE:0092 and 10DE:00F2 for bug (#179997). * Tue Feb 07 2006 Jesse Keating 1.0.1.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-palmax-1.0.0.5-1.1 ------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-penmount-1.0.0.5-1.1 --------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-s3-0.3.5.5-1.1 --------------------------- * Tue Feb 07 2006 Jesse Keating - 0.3.5.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-s3virge-1.8.6.5-1.1 -------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.8.6.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-savage-2.0.2.3-1.1 ------------------------------- * Tue Feb 07 2006 Jesse Keating - 2.0.2.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-sis-0.8.1.3-1.1 ---------------------------- * Tue Feb 07 2006 Jesse Keating - 0.8.1.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Wed Jan 18 2006 Mike A. Harris 0.8.1.3-1 - Updated xorg-x11-drv-sis to version 0.8.1.3 from X11R7.0 * Tue Dec 20 2005 Mike A. Harris 0.8.1.2-1 - Updated xorg-x11-drv-sis to version 0.8.1.2 from X11R7 RC4 - Removed 'x' suffix from manpage dirs to match RC4 upstream. xorg-x11-drv-sisusb-0.7.1.3-1.1 ------------------------------- * Tue Feb 07 2006 Jesse Keating - 0.7.1.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-spaceorb-1.0.0.5-1.1 --------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-summa-1.0.0.5-1.1 ------------------------------ * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-tdfx-1.1.1.3-1.1 ----------------------------- * Tue Feb 07 2006 Jesse Keating - 1.1.1.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-tek4957-1.0.0.1-1.1 -------------------------------- xorg-x11-drv-trident-1.0.1.2-1.1 -------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1.2-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-ur98-1.0.0.5-1.1 ----------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-vesa-1.0.1.3-1.1 ----------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-vga-4.0.0.5-1.1 ---------------------------- * Tue Feb 07 2006 Jesse Keating - 4.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-vmware-10.11.1.3-1.1 --------------------------------- * Tue Feb 07 2006 Jesse Keating - 10.11.1.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-void-1.0.0.5-1.1 ----------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-voodoo-1.0.0.5-1.1 ------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-filesystem-7.0-1 ------------------------- * Thu Feb 09 2006 Mike A. Harris 7.0-1 - Bumped version to 7.0-1 and rebuilt. xorg-x11-font-utils-1:1.0.1-1.1 ------------------------------- * Tue Feb 07 2006 Jesse Keating - 1:1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-resutils-1.0.1-1.1 --------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-server-utils-1.0.1-1.1 ------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-twm-1:1.0.1-1.1 ------------------------ * Tue Feb 07 2006 Jesse Keating - 1:1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-util-macros-1.0.1-1.1 ------------------------------ * Tue Feb 07 2006 Jesse Keating - 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-utils-1.0.1-1.1 ------------------------ * Tue Feb 07 2006 Jesse Keating - 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-xauth-1:1.0.1-1.1 -------------------------- * Tue Feb 07 2006 Jesse Keating - 1:1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-xbitmaps-1.0.1-1.1 --------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-xdm-1:1.0.1-1.1 ------------------------ * Tue Feb 07 2006 Jesse Keating - 1:1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-xfs-1:1.0.1-2 ---------------------- * Thu Feb 09 2006 Mike A. Harris 1:1.0.1-2 - Removed invocation of fc-cache from xfs initscript for bug (#179362) - Redirect stderr to /dev/null to squelch an unwanted error xfs.init (#155349) - Replace "s#^/.*:[a-z]*$##g" with "s#:unscaled$##g" in xfs.init for (#179491) - Cosmetic cleanups to spec file to satiate the banshees. * Tue Feb 07 2006 Jesse Keating 1:1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-xfwp-1.0.1-1.1 ----------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-xinit-1.0.1-1.1 ------------------------ * Tue Feb 07 2006 Jesse Keating - 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-xkb-utils-1.0.1-1.1 ---------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-xkbdata-1.0.1-2 ------------------------ * Thu Feb 09 2006 Mike A. Harris 1.0.1-2 - Added xkbdata-1.0.1-sysreq-fix-bug175661.patch to fix (#175661) xorg-x11-xsm-1.0.1-1.1 ---------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-xtrans-devel-1.0.0-3.1 ------------------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.0-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes xpdf-1:3.01-11.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 1:3.01-11.1 - rebuilt for new gcc4.1 snapshot and glibc changes xrestop-0.2-6.2 --------------- * Tue Feb 07 2006 Jesse Keating - 0.2-6.2 - rebuilt for new gcc4.1 snapshot and glibc changes xsane-0.99-2.1 -------------- * Tue Feb 07 2006 Jesse Keating - 0.99-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes xscreensaver-1:4.24-1 --------------------- * Tue Feb 07 2006 Jesse Keating - 1:4.23-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xsri-1:2.1.0-9.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 1:2.1.0-9.2 - rebuilt for new gcc4.1 snapshot and glibc changes xterm-208-1.1 ------------- * Tue Feb 07 2006 Jesse Keating - 208-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes yaboot-1.3.13-0.17 ------------------ * Thu Feb 09 2006 Paul Nasrat - 1.3.13-0.17 - Fix ofpath for multi-disk G5 (#180182) * Tue Feb 07 2006 Jesse Keating - 1.3.13-0.16.2 - rebuilt for new gcc4.1 snapshot and glibc changes yelp-2.13.4-1.1 --------------- * Tue Feb 07 2006 Jesse Keating - 2.13.4-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes yp-tools-2.8-8.2 ---------------- * Tue Feb 07 2006 Jesse Keating - 2.8-8.2 - rebuilt for new gcc4.1 snapshot and glibc changes ypbind-3:1.17.2-5.2 ------------------- * Tue Feb 07 2006 Jesse Keating - 3:1.17.2-5.2 - rebuilt for new gcc4.1 snapshot and glibc changes ypserv-2.13-10.1 ---------------- * Tue Feb 07 2006 Jesse Keating - 2.13-10.1 - rebuilt for new gcc4.1 snapshot and glibc changes zip-2.31-1.2 ------------ * Tue Feb 07 2006 Jesse Keating - 2.31-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes zisofs-tools-1.0.6-3.2 ---------------------- * Tue Feb 07 2006 Jesse Keating - 1.0.6-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes zlib-1.2.3-1.2 -------------- * Tue Feb 07 2006 Jesse Keating - 1.2.3-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 eclipse-bugzilla - 1:0.1.1_fc-6.2.i386 requires eclipse-platform = 0:3.1.2 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 gnome-applet-vm - 0.0.5-1.1.i386 requires libvir.so.0 gstreamer08-plugins - 0.8.11-6.1.i386 requires libgstcontrol-0.8.so.1 gstreamer08-plugins - 0.8.11-6.1.i386 requires /usr/bin/gst-register-0.8 gstreamer08-plugins - 0.8.11-6.1.i386 requires gstreamer08 >= 0:0.8.11 gstreamer08-plugins - 0.8.11-6.1.i386 requires libgstreamer-0.8.so.1 gstreamer08-plugins-devel - 0.8.11-6.1.i386 requires gstreamer08-devel >= 0:0.8.11 tkinter - 2.4.2-3.1.i386 requires libtix.so Broken deps for ia64 ---------------------------------------------------------- gstreamer08-plugins - 0.8.11-6.1.ia64 requires libgstreamer-0.8.so.1()(64bit) gstreamer08-plugins - 0.8.11-6.1.ia64 requires libgstcontrol-0.8.so.1()(64bit) gstreamer08-plugins - 0.8.11-6.1.ia64 requires /usr/bin/gst-register-0.8 gstreamer08-plugins - 0.8.11-6.1.ia64 requires gstreamer08 >= 0:0.8.11 gstreamer08-plugins-devel - 0.8.11-6.1.ia64 requires gstreamer08-devel >= 0:0.8.11 rgmanager - 1.9.31-3.ia64 requires ccs tkinter - 2.4.2-3.1.ia64 requires libtix.so()(64bit) Broken deps for ppc ---------------------------------------------------------- ccs-devel - 1.0.2-3.2.ppc requires ccs = 0:1.0.2-3.2 eclipse-bugzilla - 1:0.1.1_fc-6.2.ppc requires eclipse-platform = 0:3.1.2 gstreamer08-plugins - 0.8.11-6.1.ppc requires libgstcontrol-0.8.so.1 gstreamer08-plugins - 0.8.11-6.1.ppc requires /usr/bin/gst-register-0.8 gstreamer08-plugins - 0.8.11-6.1.ppc requires gstreamer08 >= 0:0.8.11 gstreamer08-plugins - 0.8.11-6.1.ppc requires libgstreamer-0.8.so.1 gstreamer08-plugins-devel - 0.8.11-6.1.ppc requires gstreamer08-devel >= 0:0.8.11 gulm - 1.0.4-2.FC5.1.ppc requires ccs tkinter - 2.4.2-3.1.ppc requires libtix.so Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 gstreamer08-plugins - 0.8.11-6.1.ppc64 requires libgstreamer-0.8.so.1()(64bit) gstreamer08-plugins - 0.8.11-6.1.ppc64 requires libgstcontrol-0.8.so.1()(64bit) gstreamer08-plugins - 0.8.11-6.1.ppc64 requires /usr/bin/gst-register-0.8 gstreamer08-plugins - 0.8.11-6.1.ppc64 requires gstreamer08 >= 0:0.8.11 gstreamer08-plugins-devel - 0.8.11-6.1.ppc64 requires gstreamer08-devel >= 0:0.8.11 tkinter - 2.4.2-3.1.ppc64 requires libtix.so()(64bit) Broken deps for s390 ---------------------------------------------------------- gstreamer08-plugins - 0.8.11-6.1.s390 requires libgstcontrol-0.8.so.1 gstreamer08-plugins - 0.8.11-6.1.s390 requires /usr/bin/gst-register-0.8 gstreamer08-plugins - 0.8.11-6.1.s390 requires gstreamer08 >= 0:0.8.11 gstreamer08-plugins - 0.8.11-6.1.s390 requires libgstreamer-0.8.so.1 gstreamer08-plugins-devel - 0.8.11-6.1.s390 requires gstreamer08-devel >= 0:0.8.11 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 tkinter - 2.4.2-3.1.s390 requires libtix.so Broken deps for s390x ---------------------------------------------------------- gstreamer08-plugins - 0.8.11-6.1.s390x requires libgstcontrol-0.8.so.1()(64bit) gstreamer08-plugins - 0.8.11-6.1.s390x requires /usr/bin/gst-register-0.8 gstreamer08-plugins - 0.8.11-6.1.s390x requires gstreamer08 >= 0:0.8.11 gstreamer08-plugins - 0.8.11-6.1.s390x requires libgstreamer-0.8.so.1()(64bit) gstreamer08-plugins-devel - 0.8.11-6.1.s390x requires gstreamer08-devel >= 0:0.8.11 libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) tkinter - 2.4.2-3.1.s390x requires libtix.so()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 eclipse-bugzilla - 1:0.1.1_fc-6.2.x86_64 requires eclipse-platform = 0:3.1.2 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnome-applet-vm - 0.0.5-1.1.x86_64 requires libvir.so.0()(64bit) gstreamer08-plugins - 0.8.11-6.1.x86_64 requires libgstreamer-0.8.so.1()(64bit) gstreamer08-plugins - 0.8.11-6.1.x86_64 requires libgstcontrol-0.8.so.1()(64bit) gstreamer08-plugins - 0.8.11-6.1.x86_64 requires /usr/bin/gst-register-0.8 gstreamer08-plugins - 0.8.11-6.1.x86_64 requires gstreamer08 >= 0:0.8.11 gstreamer08-plugins-devel - 0.8.11-6.1.x86_64 requires gstreamer08-devel >= 0:0.8.11 tkinter - 2.4.2-3.1.x86_64 requires libtix.so()(64bit) From fedora-devel-list at thebc.ch Fri Feb 10 13:24:02 2006 From: fedora-devel-list at thebc.ch (Steven F. Christ) Date: Fri, 10 Feb 2006 14:24:02 +0100 Subject: GnomeBaker MP3-Support In-Reply-To: <1139545991.2484.14.camel@localhost.localdomain> References: <561c252c0602090932j49a12c4fq@mail.gmail.com> <20060209192445.4beaafcb@python2> <1139545991.2484.14.camel@localhost.localdomain> Message-ID: <20060210142402.2314f25b@artchaos> On Fri, 10 Feb 2006 15:33:10 +1100 Rodd Clarkson wrote: > On Thu, 2006-02-09 at 19:24 +0100, Matthias Saou wrote: > > > Nope, those packages are already all made for "development" (hence > > the directory name), and in this case the package you'll need is the > > gstreamer-plugins-ugly IIRC (or -bad, I keep confusing them). > > There's three > > good: drivers work and also won't cause licensing issues > bad: drivers work but may cause licensing issues > ugly: drivers may work to some degree, licensing either/or. > > > > r. who are those plugins, on devel or extras-devel? sfc From che666 at gmail.com Fri Feb 10 13:35:43 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Fri, 10 Feb 2006 14:35:43 +0100 Subject: XGL In-Reply-To: References: <43E15BEF.3070405@mharris.ca> Message-ID: 2006/2/10, Benjy Grogan : > > On 2/1/06, Mike A. Harris wrote: > > Benjy Grogan wrote: > > > I hear that in a week or so Novell will be releasing the source code to > > > XGL for X11 7.0. Will it be possible to have XGL available in Extras > > > for FC5? I'm guessing it's one of those new X11 modules that v7.0 is > > > all about. But I know little about XGL and would like to test it out to > > > know more. It's going to be in NLD 10 in a few months. > > > > There are a lot of X related "goodies" that are up and coming in the > > X development world, including technologies being developed by Red Hat, > > Novell, Sun, and various others in the community. The current plan for > > Fedora Core 5, is to ship X11R7.0 as the official X implementation, > > including the Xorg X server. > > > > The various developmental/experimental technologies being developed > > by the above parties will most likely be available to Fedora users in > > one form or another over time, however everything is quite experimental > > at the current point in time to make any solid speculation for the > > inclusion of other components into Fedora Core 5 at this time. > > > > Maybe Fedora could do something like was done with SELinux? Where it was > available in FC2 but not by default. In an update for X11 from 7.0 to 7.1 > for FC5 the Xgl branch could be included along with instructions on how to > enable it. This is how Novell will be introducing Xgl to it's NLD10 > distribution. It seems like a good way to get Xgl tested early and it's the > perfect place for it to take place, in Fedora. > > I'm eager to see how Xgl works. :) And then I guess compiz would be the > next request. ;) > > Benji > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > would be pretty sweet. composite is dealt with the same way... disabled by default but "available" ;) regards, Rudolf Kastl p.s. if its an optional setting and isnt yet perfect i see it as rather uncritical and bugreports keep on flowing. ;) From russell at coker.com.au Fri Feb 10 14:10:48 2006 From: russell at coker.com.au (Russell Coker) Date: Sat, 11 Feb 2006 01:10:48 +1100 Subject: auid In-Reply-To: <20060209212633.62002.qmail@web51504.mail.yahoo.com> References: <20060209212633.62002.qmail@web51504.mail.yahoo.com> Message-ID: <200602110110.58098.russell@coker.com.au> On Friday 10 February 2006 08:26, Steve G wrote: > >Also every other mail server including Sendmail. > > Are they modified to set loginuid? No, currently only Postfix. > >The Postfix code supports multiple deliveries initiated from the one local > >process and I wrote code to reset the auid for this. This is one thing > > that I think is a bad idea, in fact I'll suggest to Wietse that Postfix > > be changed to only have one delivery per instance of the local process, > > fork() is cheap by any measure and particularly when compared to all the > > synchronous disk IO that occurs when a mail server is doing delivery. > > The only issue is to make sure that when it does any processing of .files > on behalf of a user, the loginuid is set for that user during the > processing of the script. After that, postfix should go back to its > original loginuid. Postfix is designed with a number of cooperating processes that perform different parts of the MTA operation. The process named "local" does local delivery, it currently may do multiple deliveries in one run, but it should be easy enough to modify it to do only one delivery every time it's executed/forked and therefore remove the need for it to reset the auid. > >Does procmail really need this? > > For situations where there is no mail server installed and cron jobs need > to deliver the mail. If there's a way to avoid procmail when there's no > postfix installed, then we don't need it. How do you do this? I guess you have some sort of -m option to crond. > >As for Sendmail, one program which does EVERYTHING including the ability > > to reset auid. > > Is sendmail modified? Not yet. -- 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 gianluca.cecchi at gmail.com Fri Feb 10 14:22:19 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Fri, 10 Feb 2006 15:22:19 +0100 Subject: rawhide report: 20060210 changes (part 2/2) Message-ID: <561c252c0602100622x7473c286h@mail.gmail.com> On Fri, 10 Feb 2006 07:57:57 -0500 Build System wrote: > readahead-1:1.2-1.24.1 > ---------------------- > * Tue Feb 07 2006 Jesse Keating - error: line 4: Tag takes single > token only: Release: :.1 1.23.1 > - rebuilt for new gcc4.1 snapshot and glibc changes [snip] > tomcat5-0:5.0.30-8jpp_10fc > -------------------------- > * Tue Feb 07 2006 Jesse Keating - sh: line 1: build-classpath: > command not found > - rebuilt for new gcc4.1 snapshot and glibc changes HIH debugging gianluca From eric at interplas.com Fri Feb 10 14:56:51 2006 From: eric at interplas.com (Eric Wood) Date: Fri, 10 Feb 2006 09:56:51 -0500 Subject: dmraid comments and a warning References: <1139256516.4440.66.camel@mentorng.gurulabs.com><1139296637.3599.24.camel@mentorng.gurulabs.com><1139351640.15968.68.camel@localhost.localdomain><200602071622.42894.lamont@gurulabs.com><1139414860.15968.98.camel@localhost.localdomain><1139416647.15968.101.camel@localhost.localdomain> <1139435297.15968.110.camel@localhost.localdomain> Message-ID: <00ee01c62e52$39ee1ca0$f502000a@M145Primary> ----- Original Message ----- From: "Peter Jones" > OK, that should be in rawhide in the next couple of days. Hopefully > tomorrow, but the build boxes are a little crowded recently. Peter, Several of us have a Fake RAID boxes (mine shuttle's are via chipsets) and are chomping at the bits to try the latest dmraid. In order to give you maximum feedback in chronological order, could you put a complete set of instructions and diagnostic commands to use over at http://fedoraproject.org/wiki/DmraidStatus? For example: 1. Non-upgrade Install rawhide on two pre-mirrored drives. 1a. After firstboot, save all metadata for reference. (fstab, blkid.tab, grub.conf, lvm.conf, pvdisplay, dmraid -rvv, dmsetup table) 1b. Disconnect secondary drive and boot on primary drive only, save all metadata for reference. 1c. Disconnect primary drive and boot on secondary drive only, save all metadata for reference. 1d. Reconnect both drives, resync drives in BIOS and boot, save all metadata for reference. (1a and 1d metadata should match?) 1e. Upgrade kernel, save all metadata for reference. 2. Non-upgrade Install rawhide on one drives (even with BIOS set the RAID enabled). 2a. After firstboot, save all metadata for reference. 2b. Connect secondary drive and establish mirror in BIOS. Boot and save all metadata for reference. (should match 1a metadata?) 3c. Upgrade kernel, save all metadata for reference. This all won't be at all tedious if you just put together a script for us to snapshot a version of the metadata. As an aside, I just find it extremely frightening that inserting and ejecting removable media has the system rewrites a file as important as fstab on every little whim. I feel that a transient media should have their own fstab file to mess up. thanks! -eric wood From aph at redhat.com Fri Feb 10 15:01:26 2006 From: aph at redhat.com (Andrew Haley) Date: Fri, 10 Feb 2006 15:01:26 +0000 Subject: JOnAS on FC5 Message-ID: <17388.43718.216981.880667@zapata.pink> JOnAS works well on FC5 test 2 w/updates. The bottom line: Tests Failures Errors Success rate Time 1837 29 9 97.93% 1565.078 (The best set of results we've ever had, AFAIK) The conformance test results are at http://people.redhat.com/aph/current-jonas-on-gcj-conformance-test-results.html. The only thing I changed in the default setup was the stack size. (We must get this change in the RPM!) I had planned to work on this a few days, but Building JOnAS on an FC5 test box turned out to be no big deal at all! The only real problem I had was with medor and jorm, which seem to depend on each other. So, I downloaded the following packages from devserv.devel and rebuilt both: jorm-2.4.3-1jpp_2fc.1.noarch.rpm jorm-javadoc-2.4.3-1jpp_2fc.1.noarch.rpm medor-1.4.4-1jpp_3fc.noarch.rpm medor-expression-1.4.2-1jpp_3fc.noarch.rpm medor-expression-javadoc-1.4.2-1jpp_3fc.noarch.rpm medor-javadoc-1.4.4-1jpp_3fc.noarch.rpm I also had to install there FC5 packages: tomcat5-servlet-2.4-api.i386 5.0.30-8jpp_9fc jdom.noarch 1.0-1jpp_2fc.1 werken.xpath.noarch 0.9.4-0.beta.9jpp_2fc velocity.noarch 1.4-3jpp_3fc struts.i386 1.2.4-2jpp_5fc tomcat5-jasper.i386 5.0.30-8jpp_9fc tomcat5.i386 5.0.30-8jpp_9fc jrefactory.noarch 2.8.9-3jpp_1fc.1.1 xjavadoc.noarch 1.1-1jpp_3fc adaptx.noarch 0.9.6-1jpp_2fc.1.1 mockobjects.noarch 0.09-12jpp_4fc concurrent.noarch 1.3.2-2jpp_1fc.1 tomcat5-webapps.i386 5.0.30-8jpp_9fc jgroups.noarch 2.2.6-1jpp_3fc classpathx-mail-monolithic.noarch 1.0-4jpp_4fc castor.noarch 0.9.5-1jpp_1fc.1.1 tomcat5-admin-webapps.i386 5.0.30-8jpp_9fc xdoclet.noarch 1.2.2-2jpp_4fc tanukiwrapper.i386 3.1.1-4jpp_3fc.2 jakarta-commons-cli.i386 1.0-6jpp_5.fc5 And the progress of rebuilding JOnAS and all of its dependencies went like this: 15:18 monolog 15:25 dtdparser 15:26 objectweb-deploysched 15:26 asm 15:27 fractal 15:28 perseus-cache 15:30 perseus-dependency 15:32 perseus-distribution 15:32 perseus-concurrency 15:58 nanoxml 16:00 oldkilim 16:02 jonathan-core 16:17 jacorb 16:22 jonathan-jeremie 16:24 carol 16:25 howl-logger 16:27 joram 16:41 perseus-pool 16:42 perseus-fos 16:43 jorm 16:44 medor 16:45 medor-expression 16:46 jotm 16:47 jorm-rdb-adapter 16:47 objectweb-anttask 16:48 perseus-persistence 16:49 p6spy 16:50 jonathan-rmi 16:50 gif89encoder 18:24 jonas Andrew. From aph at redhat.com Fri Feb 10 15:02:31 2006 From: aph at redhat.com (Andrew Haley) Date: Fri, 10 Feb 2006 15:02:31 +0000 Subject: JOnAS on FC5 In-Reply-To: <17388.43718.216981.880667@zapata.pink> References: <17388.43718.216981.880667@zapata.pink> Message-ID: <17388.43783.317256.676111@zapata.pink> OK, so my next job is to try to figure out how to get this stuff into Fedora Extras... Andrew. From jspaleta at gmail.com Fri Feb 10 15:17:14 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 10 Feb 2006 10:17:14 -0500 Subject: JOnAS on FC5 In-Reply-To: <17388.43783.317256.676111@zapata.pink> References: <17388.43718.216981.880667@zapata.pink> <17388.43783.317256.676111@zapata.pink> Message-ID: <604aa7910602100717p1e640776u365165f5db4286e6@mail.gmail.com> On 2/10/06, Andrew Haley wrote: > OK, so my next job is to try to figure out how to get this stuff into > Fedora Extras... http://www.fedoraproject.org/wiki/Extras http://www.fedoraproject.org/wiki/Extras/NewPackageProcess since you are already inside the redhat fenceline getting sponsership won't be a burden.. i think you still have to get an account through the fedora accounts system though. since jonas was moved in/out of core's development tree.. some of the review process for submission may not apply.. if jonas is considered an "orphaned" package according to the rules at: http://www.fedoraproject.org/wiki/Extras/OrphanedPackages If jonas and its deps are not considered orphaned, because jonas was not part of a previous Core "release", then they will have to go through the formal package review process outlined in http://www.fedoraproject.org/wiki/Extras/NewPackageProcess -jef From enrico.scholz at informatik.tu-chemnitz.de Fri Feb 10 15:42:55 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 10 Feb 2006 16:42:55 +0100 Subject: JOnAS on FC5 In-Reply-To: <604aa7910602100717p1e640776u365165f5db4286e6@mail.gmail.com> (Jeff Spaleta's message of "Fri, 10 Feb 2006 10:17:14 -0500") References: <17388.43718.216981.880667@zapata.pink> <17388.43783.317256.676111@zapata.pink> <604aa7910602100717p1e640776u365165f5db4286e6@mail.gmail.com> Message-ID: <8764nnp6dc.fsf@kosh.bigo.ensc.de> jspaleta at gmail.com (Jeff Spaleta) writes: > since jonas was moved in/out of core's development tree.. some of the > review process for submission may not apply.. Which part of the process do you mean here? The legal-issue check seems to be the only item which can be skipped. When a package sat in Fedora Core, this does not mean that it come into Extras without a review. Often, the Fedora Core packages are having a horrible quality which can not be accepted for Fedora Extras. Enrico From jspaleta at gmail.com Fri Feb 10 15:53:09 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 10 Feb 2006 10:53:09 -0500 Subject: JOnAS on FC5 In-Reply-To: <8764nnp6dc.fsf@kosh.bigo.ensc.de> References: <17388.43718.216981.880667@zapata.pink> <17388.43783.317256.676111@zapata.pink> <604aa7910602100717p1e640776u365165f5db4286e6@mail.gmail.com> <8764nnp6dc.fsf@kosh.bigo.ensc.de> Message-ID: <604aa7910602100753y59d62fedgcc46eeadbd7e66db@mail.gmail.com> On 2/10/06, Enrico Scholz wrote: > jspaleta at gmail.com (Jeff Spaleta) writes: > > > since jonas was moved in/out of core's development tree.. some of the > > review process for submission may not apply.. > > Which part of the process do you mean here? The legal-issue check seems > to be the only item which can be skipped. I could absolutely be wrong about my interpretation. I thought packages which use to be in Core were considered orphaned and could be moved into Extras without new submission review? -jef From enrico.scholz at informatik.tu-chemnitz.de Fri Feb 10 16:08:04 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 10 Feb 2006 17:08:04 +0100 Subject: JOnAS on FC5 In-Reply-To: <604aa7910602100753y59d62fedgcc46eeadbd7e66db@mail.gmail.com> (Jeff Spaleta's message of "Fri, 10 Feb 2006 10:53:09 -0500") References: <17388.43718.216981.880667@zapata.pink> <17388.43783.317256.676111@zapata.pink> <604aa7910602100717p1e640776u365165f5db4286e6@mail.gmail.com> <8764nnp6dc.fsf@kosh.bigo.ensc.de> <604aa7910602100753y59d62fedgcc46eeadbd7e66db@mail.gmail.com> Message-ID: <871wybp57f.fsf@kosh.bigo.ensc.de> jspaleta at gmail.com (Jeff Spaleta) writes: >> > since jonas was moved in/out of core's development tree.. some of >> > the review process for submission may not apply.. >> >> Which part of the process do you mean here? The legal-issue check seems >> to be the only item which can be skipped. > > I could absolutely be wrong about my interpretation. I thought packages > which use to be in Core were considered orphaned and could be moved > into Extras without new submission review? Most Fedora Core packages have probably never seen an 'rpmlint' run, nor were checked for orphaned directories nor tested for %doc files introducing additional deps. So I do not see how a Core -> Extras transition can be justified without a review. Enrico From aph at redhat.com Fri Feb 10 16:21:12 2006 From: aph at redhat.com (Andrew Haley) Date: Fri, 10 Feb 2006 16:21:12 +0000 Subject: JOnAS on FC5 In-Reply-To: <604aa7910602100753y59d62fedgcc46eeadbd7e66db@mail.gmail.com> References: <17388.43718.216981.880667@zapata.pink> <17388.43783.317256.676111@zapata.pink> <604aa7910602100717p1e640776u365165f5db4286e6@mail.gmail.com> <8764nnp6dc.fsf@kosh.bigo.ensc.de> <604aa7910602100753y59d62fedgcc46eeadbd7e66db@mail.gmail.com> Message-ID: <17388.48504.951258.567267@zapata.pink> Jeff Spaleta writes: > On 2/10/06, Enrico Scholz wrote: > > jspaleta at gmail.com (Jeff Spaleta) writes: > > > > > since jonas was moved in/out of core's development tree.. some of the > > > review process for submission may not apply.. > > > > Which part of the process do you mean here? The legal-issue check seems > > to be the only item which can be skipped. > > I could absolutely be wrong about my interpretation. I thought > packages which use to be in Core were considered orphaned and could be > moved into Extras without new submission review? It says here: 1. Packages, which need a new maintainer (orphaned packages). A package may need to be dropped from the distribution when it contains security vulnerabilities, gets out-of-date too much and/or becomes incompatible with build dependencies. And it seems to me that JOnAS and its dependencies fit into this category, having been dropped mainly because of dbuild dependency issues. I doubt very much that any of these packages can reasonably be described as "new submissions" -- if build problems hadn't cropped up they would have been in FC5. But on the other hand, they never made it into FC5. I don't mind, really, as long as the work involved in pushing these 30 packages into extras isn't great. Andrew. From jspaleta at gmail.com Fri Feb 10 16:27:25 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 10 Feb 2006 11:27:25 -0500 Subject: JOnAS on FC5 In-Reply-To: <871wybp57f.fsf@kosh.bigo.ensc.de> References: <17388.43718.216981.880667@zapata.pink> <17388.43783.317256.676111@zapata.pink> <604aa7910602100717p1e640776u365165f5db4286e6@mail.gmail.com> <8764nnp6dc.fsf@kosh.bigo.ensc.de> <604aa7910602100753y59d62fedgcc46eeadbd7e66db@mail.gmail.com> <871wybp57f.fsf@kosh.bigo.ensc.de> Message-ID: <604aa7910602100827p110c2178r9e76fb8fa5dd5dbe@mail.gmail.com> On 2/10/06, Enrico Scholz wrote: > So I do not see how a Core -> Extras transition can be justified without > a review. I'm not arguing that avoiding the full review process is a good idea. I'm stating the policy as I understand it. I do not personally agree with that policy and I would encourage all things which move from Core to Extras to undergo the full review process. But as I said.. my understanding of the current policy treats items that move from Core to Extras as orphaned. I'd love to see everything that moves from Core have to go through formal Extras review, but that's not the policy as I understand it and I'm not going to present my opinion and desire as policy when it is not. -jef From igorm5 at vip.hr Fri Feb 10 15:48:17 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Fri, 10 Feb 2006 16:48:17 +0100 Subject: XGL In-Reply-To: References: <43E15BEF.3070405@mharris.ca> Message-ID: <43ECB5C1.4070303@vip.hr> Benjy Grogan wrote: > Maybe Fedora could do something like was done with SELinux? Where it > was available in FC2 but not by default. In an update for X11 from 7.0 > to 7.1 for FC5 the Xgl branch could be included along with instructions > on how to enable it. This is how Novell will be introducing Xgl to it's > NLD10 distribution. It seems like a good way to get Xgl tested early > and it's the perfect place for it to take place, in Fedora. I agree. I would also like to see how it works. It would be very nice to have that feature in FC5. -- Igor Jagec From lamont at gurulabs.com Fri Feb 10 16:37:30 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Fri, 10 Feb 2006 09:37:30 -0700 Subject: XGL In-Reply-To: <43ECB5C1.4070303@vip.hr> References: <43ECB5C1.4070303@vip.hr> Message-ID: <200602100937.34405.lamont@gurulabs.com> On Friday 10 February 2006 08:48am, Igor Jagec wrote: > Benjy Grogan wrote: > > Maybe Fedora could do something like was done with SELinux? Where it > > was available in FC2 but not by default. In an update for X11 from 7.0 > > to 7.1 for FC5 the Xgl branch could be included along with instructions > > on how to enable it. This is how Novell will be introducing Xgl to it's > > NLD10 distribution. It seems like a good way to get Xgl tested early > > and it's the perfect place for it to take place, in Fedora. > > I agree. I would also like to see how it works. It would be very nice to > have that feature in FC5. +1 here. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- 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 Fri Feb 10 17:18:59 2006 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 10 Feb 2006 09:18:59 -0800 (PST) Subject: auid In-Reply-To: <200602110110.58098.russell@coker.com.au> Message-ID: <20060210171859.75750.qmail@web51507.mail.yahoo.com> >No, currently only Postfix. OK, good...none sneaked in. :) We probably should make a round of updates to extend setting loginuid to some other entry point daemons as well. But getting back to the original point I was trying to make...could we have policy restrict the applications that can set the loginuid? (It might already do it, I dont know.) >>>Does procmail really need this? >> >> For situations where there is no mail server installed and cron jobs need >> to deliver the mail. If there's a way to avoid procmail when there's no >> postfix installed, then we don't need it. >How do you do this? I guess you have some sort of -m option to crond. Yes, crond had a -m option added to it. We were looking at using procmail or a helper script. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From pbrobinson at gmail.com Fri Feb 10 17:22:28 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 10 Feb 2006 17:22:28 +0000 Subject: artifacts in gtk apps and slowness updating In-Reply-To: <1139560675.5054.1.camel@localhost.localdomain> References: <5256d0b0602091043s43166852k41fcdf884da32d38@mail.gmail.com> <1139560675.5054.1.camel@localhost.localdomain> Message-ID: <5256d0b0602100922q3e210e73l7935aec1f4ac239a@mail.gmail.com> On 2/10/06, Emeric Maschino wrote: > Hi, > > > Is it just me seeing artifacts in various gtk components on rawhide > > with all updates? Its been there a while. I'm seeing it in things like > > progess bars and the forward and back buttons on firefox. Also when I > > switch to a terminal window it seems to take forever to refresh and > > show the contents of the window. > > Nothing similar here with up-to-date Rawhide (on an ia64 system though). > Could this be related to a particular video adapter? Did you try the > vesa driver to check if these artifacts are also noticeable? removed my xorg config file and ran the system-config whatever and resetup. It seemed to fix the problem, I think it was the EXA option for my radeon display that'd I'd played with at some stage. Cheers, peter From emeric.maschino at jouy.inra.fr Fri Feb 10 17:36:20 2006 From: emeric.maschino at jouy.inra.fr (Emeric Maschino) Date: Fri, 10 Feb 2006 18:36:20 +0100 Subject: artifacts in gtk apps and slowness updating In-Reply-To: <5256d0b0602100922q3e210e73l7935aec1f4ac239a@mail.gmail.com> References: <5256d0b0602091043s43166852k41fcdf884da32d38@mail.gmail.com> <1139560675.5054.1.camel@localhost.localdomain> <5256d0b0602100922q3e210e73l7935aec1f4ac239a@mail.gmail.com> Message-ID: <1139592980.5054.44.camel@localhost.localdomain> Hi, > removed my xorg config file and ran the system-config whatever and > resetup. It seemed to fix the problem, I think it was the EXA option > for my radeon display that'd I'd played with at some stage. Which chipset? My workstation sports an AGP ATI FireGL X1 adapter (r300 chipset) and I have no artifact, whether with XAA or with EXA acceleration. Cheers, ?meric From pbrobinson at gmail.com Fri Feb 10 17:40:35 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 10 Feb 2006 17:40:35 +0000 Subject: artifacts in gtk apps and slowness updating In-Reply-To: <1139592980.5054.44.camel@localhost.localdomain> References: <5256d0b0602091043s43166852k41fcdf884da32d38@mail.gmail.com> <1139560675.5054.1.camel@localhost.localdomain> <5256d0b0602100922q3e210e73l7935aec1f4ac239a@mail.gmail.com> <1139592980.5054.44.camel@localhost.localdomain> Message-ID: <5256d0b0602100940r8d2dd70l2bc1cfe876913220@mail.gmail.com> On 2/10/06, Emeric Maschino wrote: > Hi, > > > removed my xorg config file and ran the system-config whatever and > > resetup. It seemed to fix the problem, I think it was the EXA option > > for my radeon display that'd I'd played with at some stage. > > Which chipset? My workstation sports an AGP ATI FireGL X1 adapter (r300 > chipset) and I have no artifact, whether with XAA or with EXA > acceleration. lspci gives me 'ATI Technologies Inc Radeon R250 Lf [FireGL 9000] (rev 02)' Its a ATI Radeon Mobility M9 in a Dell Latitude D600 laptop. Pete From twaugh at redhat.com Fri Feb 10 17:55:52 2006 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 10 Feb 2006 17:55:52 +0000 Subject: New printer admin tool design for comments Message-ID: <20060210175552.GL16000@redhat.com> I sent a previous draft of this to fedora-maintainers. Having updated it from the very useful feedback I received, I'm now sending this to a wider audience for more review. (Also: anyone who feels like helping to implement any of this, speak up!) Tim. */ A NEW PRINTER ADMINISTRATION TOOL ================================= Draft 3, Feb 10th 2006 Tim Waugh 1. PROBLEMS -------- 1.1. Alchemist --------- There are various reasons for redesigning the current system-config-printer configuration tool. A brief summary is: * the XML file format it uses is inflexible * the configuration options are limited to those common to both spoolers we were shipping at the time the XML format was decided * it is VERY SLOW: you can't *modify* configuration, only write out entirely new configurations (i.e. trigger the back-end) * again, due to the XML format chosen, we are tied to the foomatic database in such as way that we absolutely require foomatic to know about the printer before we can configure it. Even if you have the manufacturer's PPD file, there is very little you can do to get your printer working. * changes made using the CUPS configuration interface (http://localhost:631/), or any other method external to system-config-printer, are not reflected in the XML file and so cannot be modified and often get overwritten. * new CUPS backends such as hpfax or cups-pdf cannot be used without patching system-config-printer. 1.2. Stateless Linux --------------- An extra consideration to take into account when re-designing the administration tool is Stateless Linux. The requirement from that project is that users may specify their own (private) queues for submitting jobs to. For example, a particular user may want to print to an SMB printer, with certain default settings such as which input tray to use. With Stateless Linux, this queue definition will be tied to the user's home directory so that they can log in on any stateless workstation and be able to print to their queue. 2. SOLUTIONS --------- 2.1. Stateless Linux --------------- A Stateless Linux configuration has /etc read-only. This causes a problem with local printers: automatic detection of a local printer needs to add a queue. This runtime configuration means that the CUPS configuration files, currently stored in /etc/cups, should be moved to /var/run. Since /var/run does not preserve data over a reboot, this should only be done for stateless configurations. One possible trigger for this special stateless behaviour would be for CUPS to detect that /etc is read-only -- or else, it could be a configuration option. 2.1.2. (intentionally left blank) 2.1.3. Per-user queues in system CUPS daemon ------------------------------------- At session start, for each per-user queue defined by the user, the CUPS daemon is notified that a per-user queue needs to be created (if it does not already exist). This could be done using D-BUS. Firstly, the CUPS daemon is told to remove all per-user queues for this user IF they are not processing jobs. Then, for each per-user queue the CUPS daemon is given the PPD file from the user's home directory, and the URI for the printer, as well as the queue name. Given this information, the CUPS daemon will then: * copy the PPD into its ppd directory * set up a queue if it does not already exist This new queue will NOT be advertised in IPP "browse" broadcasts. Jobs may only be submitted to this queue by the owning user at the local machine, i.e.: cupsd.conf: ----------- | Allow from localhost | | AuthClass Basic | ---------------------- printers.conf: ------ | AllowUser the_user | -------------------- In addition to the current "certificates" method of avoiding the need to type in a password when submitting jobs, we could patch CUPS to use D-BUS for the same purpose. REMAINING QUESTIONS: Should steps be taken to avoid accidentally forming round-robin classes with other per-user or remote queues of the same name as the user-defined queue? One suggestion is to use 'user-$uid-$queue' as the real name, but present it to the user as '$queue'. 2.2. Better configuration method --------------------------- It will solve many of the configuration issues mentioned in 1.1 if a new printer administration tool would configure CUPS directly rather than maintaining a separate configuration file. There are two main ways of doing this: * using the command-line tools such as lpadmin and lpoptions * using IPP to communicate with the CUPS daemon directly Using IPP directly will offer more flexibility. Some of the more subtle changes we will need to make may not be possible using command-line tools alone. Additionally, using IPP for configuration allows the possibility of configuring remote CUPS instances using the graphical tool, and this will be important for print servers that do not have a full graphical interface installed. Additionally, the user interface must provide a method for the administrator to enable and disable queues. Some queues can get disabled as a result of an error detected by the backend, and there is currently no means of re-enabling the queue using the existing graphical interface. 2.2.1. Configuration items not possible using IPP ------------------------------------------ In order to configure items in /etc/cups/cupsd.conf, the file must be altered and the CUPS daemon told to re-read its configuration. The IPP interface does not offer any way of configuring settings in this file -- since the ability to use the IPP interface at all is part of that configuration. Things that the administration tool may need to change that reside in cupsd.conf: * access controls for each local queue * whether to enable CUPS browsing (both listening and broadcasting) * what network interfaces to listen on Previously these settings were stored in alchemist and written out to cupsd.conf, over-writing any previous conflicting settings. It is very important that cupsd.conf be the canonical place for these settings. The existing settings should be shown to the user so that they can be modified. Editing cupsd.conf by hand must not cause any problems with the administration tool. 2.3. IPP authentication ------------------ There are two options: * The admin tool runs with user privileges. An authentication dialog box will appear when configuring the CUPS daemon using IPP. Some mechanism similar to consolehelper needs to be devised in order to avoid the need to keep asking for passwords. (This is my preferred alternative.) -or- * The admin tool uses consolehelper as before, but can run in unprivileged mode in order to configure only per-user queues. 2.4. Modifying PPD options --------------------- The new printer administration tool will be responsible for providing a graphical interface for changing the "InstallableOptions" (such as whether a duplexer is installed) and the default queue options such as duplexing, page size, and print quality. All of these options are stored in the PPD file representing the queue, and this is modified by the CUPS daemon when it receives the IPP request to do so. The GTK+ print dialog will also allow these settings (except those in the InstallableOptions group) to be over-ridden on a per-job basis. The user interface will be largely the same, and there is opportunity for code-sharing here. Some aspects of PPD option representation (such as grouping and constraints) require careful implementation in the user interface, and so it would be better not to duplicate this work. 2.5. Page size as a special case --------------------------- When adding a new queue for an automatically detected printer, an appropriate default page size should be chosen based on the system locale. CUPS will already do this for us when a new queue is created, so there is no action to be taken. 2.6. Persistent settings ------------------- Unplugging a USB printer and re-attaching it must retain the settings it had prior to unplugging. This needs to be handled by HAL. 2.6.1. Simple persistence ------------------ One easy method is to avoid automatically removing queues at all. Instead, the queue could be disabled (i.e. cupsdisable) when the device is unplugged, and enabled when inserted. For this to be feasible, it must be possible to identify a newly-inserted printer as being the same one that had been unplugged previously. Many USB printers provide a serial number in their IEEE 1284 Device ID string which can be used for this purpose. If there is no serial number available, the manufacturer and model strings could be used to identify the correct queue to act upon. If there is no (disabled) queue identified, a new queue would be created as in 2.7 "Automatic detection", below. The proposal that persistent settings be handled by simply disabling/enabling queues rather than removing queues altogether means that persistent settings can be managed entirely by HAL. 2.6.2. More advanced persistence ------------------------- Once the new administration tool works well, the persistent settings idea could be made more advanced. See 2.10.3 "More advanced persistence" for how this could work. 2.7. Automatic detection ------------------- A local printer will be automatically detected by HAL and an appropriate queue created for it. 2.7.2. Remote discovery ---------------- For remote printers, the common types are: SMB, JetDirect, and IPP/CUPS. IPP/CUPS instances can broadcast browse packets to facilitate automatic detection for clients. We already make use of this. For JetDirect printers there is no way of automatically finding them other than probing each address on the subnet. For SMB printers there may very well be a means of actively discovering remote queues automatically, perhaps by querying the domain server and then each named SMB host in turn. However, I think authentication details (such as username/password) need to be configured when you create a queue, rather than when a job is submitted -- the information is placed into the URI for the queue. I am not aware of a passive discovery method for SMB. It has been suggested that UPnP could be used for remote discovery of some newer network printers. 2.7.1. Method for creating a queue --------------------------- The vast majority of printers provide IEEE 1284 Device ID strings to identify themselves. These strings provide: manufacturer name, model name, description, and command sets understood by the device. For example: MFG:EPSON;CMD:ESCPL2,BDC,D4;MDL:Stylus Photo 830U;CLS:PRINTER;DES:EPSON Stylus Photo 830U; or: MFG:Hewlett-Packard;CMD:PJL,MLC,PCL,PCLXL,POSTSCRIPT;MDL:HP LaserJet 1200;CLS:PRINTER;DES:Hewlett-Packard LaserJet 1200;MEM:8MB The foomatic RPM package provides a database of printers and printer drivers. It stores IEEE 1284 Device ID strings for a large number of printers. It also stores information about which drivers may be used with a given device, and which of those is recommended. When a local printer is detected, its IEEE 1284 Device ID string should be retrieved. For parallel port printers, /proc/sys/dev/parport/*/autoprobe provides this; for USB printers, /sys/devices/*/*/usb*/*/*/ieee1284_id provides it in newer kernels (>= 2.6.15-1.1826.2.6.FC5). The foomatic database should then be consulted to look up a printer model based on the manufacturer and model IEEE 1284 Device ID fields. (NB: printconf currently uses some tricks to match printer models for those whose IEEE 1284 Device IDs are not known to foomatic). If no printer is found, the command set field should be examined. If "POSTSCRIPT" is found, the generic PostScript driver can be used. If "PCLXL" is found, the generic PCL 6/PCL XL driver can be used. If "PCL" is found, the generic PCL 3 driver can be used. Otherwise, a manufacturer's PPD is required from the user. If the printer was found, and there is a manufacturer-provided PPD available for the recommended driver for it (a PPD is specific to a printer model and driver combination), the queue is set up automatically and needs no user intervention. If there was no manufacturer-provided PPD (including the case where the printer was not found in the database), the user should be asked to see if they have a manufacturer-provided PPD file. On creating the queue, the page size needs to be adjusted appropriately for the locale. 2.7.2. Code sharing ------------ IEEE 1284 Device ID strings may also be provided by remote printers that are SNMP-capable. There are some subtleties in creating a new queue, such as altering the page size. As a result, the mechanism for creating a queue outlined in 2.7.1 needs to be used for: a) automatically detected printers b) adding printers using the admin tool c) adding per-user remote queues 2.8. Admin tool for creating system queues and per-user queues --------------------------------------------------------- If it makes sense from a user interface perspective, it would be useful to combine the facility for creating and editing per-user queues into the admin tool, since a lot of the same functionality is needed. Additionally, in order to keep the queue creation logic in one place, it might very well make sense for HAL to hand off the IEEE 1284 information from a detected local printer to the admin tool rather than trying to configure a queue on its own. (NB: This bit needs someone with some user interface sense:) Perhaps the interface could have two tabs, one for "System print queues" and another for "My print queues". Browsed queues would not be shown. For each tab, the queues could be listed exactly as they are in the GTK+ print dialog (including number of jobs in queue, and the location). Queue sharing will be allowed for "System queues" (as currently) but not for "My queues". Editing a queue will allow the same things to be edited as currently: which driver to use; driver options; queue options such as banner pages. This combined printer administration tool would be launched by the GTK+ print dialog's "Add printer" button. 2.8.1. Ability to specify queue URI ---------------------------- The new administration tool must allow the user to specify a queue URI in the same manner as the http://localhost:631/ interface does. In other words, a list of possible URIs obtained using the IPP equivalent of '/usr/sbin/lpinfo -v', with the possibility of editing the URI. 2.9. Error handling -------------- The foomatic we are shipping for Fedora Core 5 provides a special CUPS backend: beh (backend error handler). It allows the administrator to modify the behaviour of the backends when errors are encountered: whether to try again, how many times to do that, and so on. It would be useful to be able to offer this in a user interface. The per-user queues would mean that an unprivileged user would even be able to modify error handling for their own jobs. 2.10. Future directions ----------------- The main aim is to re-implement the current limited functionality of system-config-printer in such a way that it is no longer tied to alchemist. Having an administration tool which can configure CUPS directly and interact with queues created by other means (such as http://localhost:631/ or the lpadmin command) will allow future enhancements. Some such enhancements are listed below. 2.10.1. Ink levels and maintenance functions ------------------------------------ Although there is no unified way of doing so yet, a future enhancement to the administration tool would be to allow the administrator to check ink levels and perform functions like aligning/changing cartridges, for printers that have such a facility. 2.10.2. Classes ------- Once the new administration tool works well, support could be added for configuring collections of printers (CUPS classes), where a job sent to a class is directed to the first available printer in that class. 2.10.3. More advanced persistence ------------------------- HAL could (call a program which would) maintain a simple database mapping printer models to PPDs. When a printer is unplugged, the associated queue would be located and the PPD retrieved from the CUPS daemon. The manufacturer and model would be remembered and stored with the PPD. When a printer of the same manufacturer and model is inserted at a later time, the remembered PPD would be used rather than consulting foomatic (see 2.7.1 "Method for creating a queue"). This will preserve: * which driver to use * the default values for options * the InstallableOptions (such as whether a duplexer is available) 2.11. Beyond scope ------------ There are other things that need fixing with printing, such as status feedback to find out if the ink has hit the paper. These are beyond the scope of the administration tool. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From zboszor at freemail.hu Fri Feb 10 18:02:56 2006 From: zboszor at freemail.hu (Zoltan Boszormenyi) Date: Fri, 10 Feb 2006 19:02:56 +0100 Subject: XGL In-Reply-To: References: <43E15BEF.3070405@mharris.ca> <58d389c20602052158k7830e344v3598723df964cda8@mail.gmail.com> <1139218543.9515.6.camel@price.stavtrup-st.dk> <1139218686.9515.8.camel@price.stavtrup-st.dk> Message-ID: <43ECD550.3020404@freemail.hu> Hi, Benjy Grogan ?rta: > There are some cool Xgl demos at > > Benji And the whole presentation of the XDevConf talk, without sound: http://www.freedesktop.org/~davidr/xgl-demo1.xvid.avi Pretty impressive, too. I liked the task switcher with live thumbnails best. Best regards, Zolt?n B?sz?rm?nyi From pozsy at uhulinux.hu Fri Feb 10 18:06:46 2006 From: pozsy at uhulinux.hu (Pozsar Balazs) Date: Fri, 10 Feb 2006 19:06:46 +0100 Subject: rawhide report: 20060210 changes (part 1/2) In-Reply-To: <200602101257.k1ACviK4014258@porkchop.devel.redhat.com> References: <200602101257.k1ACviK4014258@porkchop.devel.redhat.com> Message-ID: <20060210180646.GA15822@ojjektum.uhulinux.hu> On Fri, Feb 10, 2006 at 07:57:44AM -0500, Build System wrote: [...] > - rebuilt for new gcc4.1 snapshot and glibc changes [...] I am wondering long ago about these changelog entries... Why are rebuilds mentioned in the changelogs? Strictly speaking, these are not changes, at least not to the .src.rpm. And by the way, I also fail to see why rebuilds are so special. Why aren't all packages rebuilt periodically by the build system? (Say, once a week or fortnight.) I think it can be easily seen that it would be a nice regular qa test, and also it would make sure that all gcc/glibc or any other library/compiler toolchain element changes/improvements would be propageted in regular and short timebase. bye, -- pozsy From katzj at redhat.com Fri Feb 10 18:17:05 2006 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 10 Feb 2006 13:17:05 -0500 Subject: rawhide report: 20060210 changes (part 1/2) In-Reply-To: <20060210180646.GA15822@ojjektum.uhulinux.hu> References: <200602101257.k1ACviK4014258@porkchop.devel.redhat.com> <20060210180646.GA15822@ojjektum.uhulinux.hu> Message-ID: <1139595425.18359.14.camel@bree.local.net> On Fri, 2006-02-10 at 19:06 +0100, Pozsar Balazs wrote: > On Fri, Feb 10, 2006 at 07:57:44AM -0500, Build System wrote: > [...] > > - rebuilt for new gcc4.1 snapshot and glibc changes > [...] > > I am wondering long ago about these changelog entries... Why are > rebuilds mentioned in the changelogs? Strictly speaking, these are not > changes, at least not to the .src.rpm. Because otherwise, if I have foo-1.2.1-1 installed and see foo-1.2.1-2, how do I know what changed without diffing src.rpms? That's what the entire purpose of the changelog is. > And by the way, I also fail to see why rebuilds are so special. Why > aren't all packages rebuilt periodically by the build system? > (Say, once a week or fortnight.) > I think it can be easily seen that it would be a nice regular qa test, > and also it would make sure that all gcc/glibc or any other > library/compiler toolchain element changes/improvements would be > propageted in regular and short timebase. There are more regular builds of everything for testing, but pushing things out just ends up causing a lot more bandwidth usage than its worth. Most packages get churned enough in the development tree that any changes get propagated to packages quickly enough. Jeremy From toshio at tiki-lounge.com Fri Feb 10 18:42:27 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 10 Feb 2006 10:42:27 -0800 Subject: JOnAS on FC5 In-Reply-To: <604aa7910602100827p110c2178r9e76fb8fa5dd5dbe@mail.gmail.com> References: <17388.43718.216981.880667@zapata.pink> <17388.43783.317256.676111@zapata.pink> <604aa7910602100717p1e640776u365165f5db4286e6@mail.gmail.com> <8764nnp6dc.fsf@kosh.bigo.ensc.de> <604aa7910602100753y59d62fedgcc46eeadbd7e66db@mail.gmail.com> <871wybp57f.fsf@kosh.bigo.ensc.de> <604aa7910602100827p110c2178r9e76fb8fa5dd5dbe@mail.gmail.com> Message-ID: <1139596947.3394.9.camel@localhost> On Fri, 2006-02-10 at 11:27 -0500, Jeff Spaleta wrote: > I'm not arguing that avoiding the full review process is a good idea. > I'm stating the policy as I understand it. I do not personally agree > with that policy and I would encourage all things which move from Core > to Extras to undergo the full review process. But as I said.. my > understanding of the current policy treats items that move from Core > to Extras as orphaned. > I'd love to see everything that moves from Core have to go through > formal Extras review, but that's not the policy as I understand it and > I'm not going to present my opinion and desire as policy when it is > not. Ask and your wish shall be granted. Message from spot:: https://www.redhat.com/archives/fedora-extras-list/2005-August/msg00750.html After talking with Warren and Greg, we're eliminating the "Previously in Core" loophole. In the past, packages which were in Fedora Core were able to be imported into Fedora Extras without review. This is no longer permitted. (This was never in writing, at least not anywhere I can see) Just to repeat: All packages MUST go through review before being committed into Fedora Extras CVS. No exceptions. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Fri Feb 10 18:48:12 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 10 Feb 2006 13:48:12 -0500 Subject: JOnAS on FC5 In-Reply-To: <1139596947.3394.9.camel@localhost> References: <17388.43718.216981.880667@zapata.pink> <17388.43783.317256.676111@zapata.pink> <604aa7910602100717p1e640776u365165f5db4286e6@mail.gmail.com> <8764nnp6dc.fsf@kosh.bigo.ensc.de> <604aa7910602100753y59d62fedgcc46eeadbd7e66db@mail.gmail.com> <871wybp57f.fsf@kosh.bigo.ensc.de> <604aa7910602100827p110c2178r9e76fb8fa5dd5dbe@mail.gmail.com> <1139596947.3394.9.camel@localhost> Message-ID: <604aa7910602101048h5004bb06wf8870f46c8c80a48@mail.gmail.com> On 2/10/06, Toshio Kuratomi wrote: > All packages MUST go through review before being committed into Fedora > Extras CVS. No exceptions. excellent! I'm more than happy to be wrong about this whole affair. -jef From jkeating at redhat.com Fri Feb 10 19:04:28 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 10 Feb 2006 11:04:28 -0800 Subject: Massive rebuild in progress In-Reply-To: <1139340272.3579.23.camel@ender> References: <1139340272.3579.23.camel@ender> Message-ID: <1139598268.2892.45.camel@ender> On Tue, 2006-02-07 at 11:24 -0800, Jesse Keating wrote: > After a late night of staging, I have 900~ packages queued up to rebuild > for the gcc4.1 snapshot and glibc changes. These will be submitted to > our build system throughout the day as low priority jobs. Some will be > finished for tonight's rawhide push, but not all of them. There are > still some packages that should be rebuilt that are not in my list, but > those package maintainer's have expressed desire to bump their packages > themselves. Over the next couple days I'll be checking package > timestamps and keeping an eye on what else needs to build. Please bear > with the churn and the very lengthy rawhide reports. A late breaking bug was found that affects ppc32/64 systems, and so I have to rebuild every package that is built on these arches over the weekend. Please wait on rebuilding Extras until this is done. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-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 Feb 10 19:11:37 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 10 Feb 2006 11:11:37 -0800 Subject: JOnAS on FC5 In-Reply-To: <17388.48504.951258.567267@zapata.pink> References: <17388.43718.216981.880667@zapata.pink> <17388.43783.317256.676111@zapata.pink> <604aa7910602100717p1e640776u365165f5db4286e6@mail.gmail.com> <8764nnp6dc.fsf@kosh.bigo.ensc.de> <604aa7910602100753y59d62fedgcc46eeadbd7e66db@mail.gmail.com> <17388.48504.951258.567267@zapata.pink> Message-ID: <1139598697.3394.23.camel@localhost> On Fri, 2006-02-10 at 16:21 +0000, Andrew Haley wrote: > It says here: > > 1. > > Packages, which need a new maintainer (orphaned packages). A > package may need to be dropped from the distribution when it > contains security vulnerabilities, gets out-of-date too much > and/or becomes incompatible with build dependencies. > > And it seems to me that JOnAS and its dependencies fit into this > category, having been dropped mainly because of dbuild dependency > issues. I doubt very much that any of these packages can reasonably > be described as "new submissions" -- if build problems hadn't cropped > up they would have been in FC5. > Hmm... This looks like it may contradict the post that I quoted earlier from spot. I suspect this predates spot's post and should be removed or rephrased on the wiki. Do you want to jump in and clarify things, spot? > But on the other hand, they never made it into FC5. > > I don't mind, really, as long as the work involved in pushing these 30 > packages into extras isn't great. Depends on what the packages look like and who shows up to review. It's peer review on a package by package basis with the guidelines posted on the wiki as the basic requirements that need to be met. http://www.fedoraproject.org/wiki/Packaging/ReviewGuidelines http://www.fedoraproject.org/wiki/Packaging/Guidelines -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dravet at hotmail.com Fri Feb 10 19:59:25 2006 From: dravet at hotmail.com (Jason Dravet) Date: Fri, 10 Feb 2006 13:59:25 -0600 Subject: pc hangs when I exit X after yesterdays rawhide update Message-ID: Ever since I updated to yesterdays rawhide (Feb 9th) I cannot logout of X windows without my PC stopping to respond. When I exit X I get a black screen, but I cannot type anything. The only two things that work are the power button and CTRL-ALT-Delete. If I press the power button the PC shuts down like it should, if I CTRL-ALT-Delete the PC reboots. I would open a bugzilla about this but to which package would I assign it? I have a tyan tiger 100 motherboard (S1832), P3 850Mhz CPU, 384MB RAM, Adaptec 2930U2 scsi card with 2 western digital 9GB scsi hard drives, 1 ide cdrom burner, a number 9 Revolution IV video card with 32MB of RAM, and a SGI 1600SW LCD panel. As I said eariler this started with yesterdays rawhide update and todays rawhide does not fix the problem. What can I do to give you enough information to fix the problem? Thanks, Jason From vonbrand at inf.utfsm.cl Mon Feb 6 14:52:34 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Mon, 06 Feb 2006 11:52:34 -0300 Subject: caution with latest kernel + glibc In-Reply-To: Your message of "Sat, 04 Feb 2006 13:12:26 -0800." <43E518BA.3010207@redhat.com> Message-ID: <200602061455.k16EqYqI003278@laptop11.inf.utfsm.cl> Ulrich Drepper wrote: > Those who are running the current rawhide kernel and glibc (and > coreutils or those trying to compile glibc for themselves) might find > that their kernel locks up. One bug in this area (I think there is more > than one) is fixed by the patch in > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178558 > > The 1909 kernel and later will likely have the patch. For now it might > be best to use glibc-2.3.90-30 and nothing later or alternatively live > with the lockups for today. The fixed kernel is hopefully in tomorrow's > rawhide. How about vanilla kernels? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From davej at redhat.com Fri Feb 10 22:14:31 2006 From: davej at redhat.com (Dave Jones) Date: Fri, 10 Feb 2006 17:14:31 -0500 Subject: caution with latest kernel + glibc In-Reply-To: <200602061455.k16EqYqI003278@laptop11.inf.utfsm.cl> References: <43E518BA.3010207@redhat.com> <200602061455.k16EqYqI003278@laptop11.inf.utfsm.cl> Message-ID: <20060210221431.GH31949@redhat.com> On Mon, Feb 06, 2006 at 11:52:34AM -0300, Horst von Brand wrote: > Ulrich Drepper wrote: > > Those who are running the current rawhide kernel and glibc (and > > coreutils or those trying to compile glibc for themselves) might find > > that their kernel locks up. One bug in this area (I think there is more > > than one) is fixed by the patch in > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178558 > > > > The 1909 kernel and later will likely have the patch. For now it might > > be best to use glibc-2.3.90-30 and nothing later or alternatively live > > with the lockups for today. The fixed kernel is hopefully in tomorrow's > > rawhide. > > How about vanilla kernels? Has this bug fixed for a few days now. Dave From dax at gurulabs.com Fri Feb 10 22:50:36 2006 From: dax at gurulabs.com (Dax Kelson) Date: Fri, 10 Feb 2006 15:50:36 -0700 Subject: gaim In-Reply-To: <43EC4A99.8060206@redhat.com> References: <200602091507.k19F7p2g012345@porkchop.devel.redhat.com> <43EB7768.2080301@insitesinc.com> <43EBA2E7.1060109@redhat.com> <1139544108.3580.18.camel@mentorng.gurulabs.com> <43EC4A99.8060206@redhat.com> Message-ID: <863-SnapperMsg827D11E1C012CA33@[68.27.211.5]> ...... Original Message ....... On Thu, 09 Feb 2006 22:11:05 -1000 "Warren Togami" wrote: >Dax Kelson wrote: >> On Thu, 2006-02-09 at 10:15 -1000, Warren Togami wrote: >>> No plans when upstream says it isn't ready, and we need to ship >>> something stable in FC5 final. Might consider upgrading it to gaim2 >>> later after FC5 release if it is in good shape. >>> >>> Warren Togami >> >> The gaim 2.0 betas support Cyrus-SASL and GSSAPI/Kerberos authentication >> with Jabber. You get the standard single sign-on bliss and solve the >> plain text password stored in ~/.gaim/accounts.xml problem. >> >> If FC5 is shipping gaim v1.5 would you apply a patch to it to add >> GSSAPI/Kerberos Jabber authentication support? >> >> We use both 2.0 beta and the 1.5+patch here at our office against our >> kerberized Jabber server. We love it. >> >> Dax Kelson >> Guru Labs >> > >I will patch gaim-1.5.x only if upstream gaim includes the patch in CVS >of that branch. I will not diverge from upstream. 2.0 has the patch so by accepting for 1.5 you would not be diverging. Want me to bugzilla it? ___ Dax Kelson Sent with my Treo From russell at coker.com.au Sat Feb 11 03:51:22 2006 From: russell at coker.com.au (Russell Coker) Date: Sat, 11 Feb 2006 14:51:22 +1100 Subject: auid In-Reply-To: <20060210171859.75750.qmail@web51507.mail.yahoo.com> References: <20060210171859.75750.qmail@web51507.mail.yahoo.com> Message-ID: <200602111451.31875.russell@coker.com.au> On Saturday 11 February 2006 04:18, Steve G wrote: > >>>Does procmail really need this? > >> > >> For situations where there is no mail server installed and cron jobs > >> need to deliver the mail. If there's a way to avoid procmail when > >> there's no postfix installed, then we don't need it. > > > >How do you do this? I guess you have some sort of -m option to crond. > > Yes, crond had a -m option added to it. We were looking at using procmail > or a helper script. What is the aim of this? If the aim is to secure the system (by reducing the number of privileged programs) then that doesn't seem like a good way of doing it, the consensus of opinion seems to be that Postfix code is better written than Procmail code in terms of security. If the aim is to have a simple configuration of the system then perhaps we should have a simple smtp client program that just makes a connection to a smart-host and sends the data through. -- 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 jkeating at redhat.com Sat Feb 11 08:24:38 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 11 Feb 2006 00:24:38 -0800 Subject: No rawhide release just yet Message-ID: <1139646279.31644.17.camel@ender> There is an error in the run, and since I'm rebuilding a lot of packages I want to wait until the packages are done before manually running the rawhide release. Sorry for the delay. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rhally at mindspring.com Sat Feb 11 08:35:08 2006 From: rhally at mindspring.com (Richard Hally) Date: Sat, 11 Feb 2006 03:35:08 -0500 Subject: No rawhide release just yet In-Reply-To: <1139646279.31644.17.camel@ender> References: <1139646279.31644.17.camel@ender> Message-ID: <43EDA1BC.1070105@mindspring.com> Jesse Keating wrote: > There is an error in the run, and since I'm rebuilding a lot of packages > I want to wait until the packages are done before manually running the > rawhide release. Sorry for the delay. > > NP, how far along are we with this whole rebuild drill? half? two-thirds? From jkeating at redhat.com Sat Feb 11 08:39:00 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 11 Feb 2006 00:39:00 -0800 Subject: No rawhide release just yet In-Reply-To: <43EDA1BC.1070105@mindspring.com> References: <1139646279.31644.17.camel@ender> <43EDA1BC.1070105@mindspring.com> Message-ID: <1139647140.31644.19.camel@ender> On Sat, 2006-02-11 at 03:35 -0500, Richard Hally wrote: > NP, how far along are we with this whole rebuild drill? half? > two-thirds? In this iteration, about 1/3rd into the way. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wtogami at redhat.com Sat Feb 11 08:53:20 2006 From: wtogami at redhat.com (Warren Togami) Date: Fri, 10 Feb 2006 22:53:20 -1000 Subject: gaim In-Reply-To: <863-SnapperMsg827D11E1C012CA33@[68.27.211.5]> References: <200602091507.k19F7p2g012345@porkchop.devel.redhat.com> <43EB7768.2080301@insitesinc.com> <43EBA2E7.1060109@redhat.com> <1139544108.3580.18.camel@mentorng.gurulabs.com> <43EC4A99.8060206@redhat.com> <863-SnapperMsg827D11E1C012CA33@[68.27.211.5]> Message-ID: <43EDA600.8030803@redhat.com> Dax Kelson wrote: > ...... Original Message ....... > On Thu, 09 Feb 2006 22:11:05 -1000 "Warren Togami" > wrote: >> Dax Kelson wrote: >>> On Thu, 2006-02-09 at 10:15 -1000, Warren Togami wrote: >>>> No plans when upstream says it isn't ready, and we need to ship >>>> something stable in FC5 final. Might consider upgrading it to gaim2 >>>> later after FC5 release if it is in good shape. >>>> >>>> Warren Togami >>> The gaim 2.0 betas support Cyrus-SASL and GSSAPI/Kerberos authentication >>> with Jabber. You get the standard single sign-on bliss and solve the >>> plain text password stored in ~/.gaim/accounts.xml problem. >>> >>> If FC5 is shipping gaim v1.5 would you apply a patch to it to add >>> GSSAPI/Kerberos Jabber authentication support? >>> >>> We use both 2.0 beta and the 1.5+patch here at our office against our >>> kerberized Jabber server. We love it. >>> >>> Dax Kelson >>> Guru Labs >>> >> I will patch gaim-1.5.x only if upstream gaim includes the patch in CVS >> of that branch. I will not diverge from upstream. > > 2.0 has the patch so by accepting for 1.5 you would not be diverging. > > Want me to bugzilla it? > ___ > Dax Kelson > Sent with my Treo I mean, convince gaim to merge this patch into their oldstatus branch. None of the patches in Fedora gaim diverge from upstream CVS. (Except for the stupid URL handler behavior...) Warren Togami wtogami at redhat.com From tmus at tmus.dk Sat Feb 11 10:58:43 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Sat, 11 Feb 2006 11:58:43 +0100 Subject: Linux-HA? In-Reply-To: <43EAB20D.3060703@redhat.com> References: <1139453765.17114.103.camel@dragon.sys.intra> <43EAB20D.3060703@redhat.com> Message-ID: Tim Burke wrote: > Heartbeat isn't in extras. Rather, there is the "Red Hat Cluster > Suite". This provides more than just the simple capabilities of > heartbeat. It includes the host membership, ability to designate > resources (ie applications start/stop as well as startup config like > mounts & IP addresses). There's even a config GUI to setup and monitor. You should probably check out heartbeat v2 faq or something http://linux-ha.org/NewHeartbeatDesign Despite the name, heartbeat does more than heartbeating. R2 has >2 node cluster capabilities, resource monitoring, resource dependencies, yada yada... In other words, heartbeat is more than just simple capabilities. /Thomas From petro at mail.ru Sat Feb 11 11:35:59 2006 From: petro at mail.ru (Peter Lemenkov) Date: Sat, 11 Feb 2006 14:35:59 +0300 Subject: pc hangs when I exit X after yesterdays rawhide update In-Reply-To: References: Message-ID: On Fri, 10 Feb 2006, Jason Dravet wrote: > Ever since I updated to yesterdays rawhide (Feb 9th) I cannot logout of X > windows without my PC stopping to respond. When I exit X I get a black > screen, but I cannot type anything. The only two things that work are the > power button and CTRL-ALT-Delete. The same thing. -- With best regards, Peter Lemenkov. From dgregor at redhat.com Sat Feb 11 19:39:47 2006 From: dgregor at redhat.com (Dennis Gregorovic) Date: Sat, 11 Feb 2006 14:39:47 -0500 Subject: rawhide report: 20060210 changes (part 2/2) In-Reply-To: <561c252c0602100622x7473c286h@mail.gmail.com> References: <561c252c0602100622x7473c286h@mail.gmail.com> Message-ID: <1139686787.4693.5.camel@localhost.localdomain> On Fri, 2006-02-10 at 15:22 +0100, Gianluca Cecchi wrote: > On Fri, 10 Feb 2006 07:57:57 -0500 Build System wrote: > > readahead-1:1.2-1.24.1 > > ---------------------- > > * Tue Feb 07 2006 Jesse Keating - error: line 4: Tag takes single > > token only: Release: :.1 1.23.1 > > - rebuilt for new gcc4.1 snapshot and glibc changes > [snip] > > tomcat5-0:5.0.30-8jpp_10fc > > -------------------------- > > * Tue Feb 07 2006 Jesse Keating - sh: line 1: build-classpath: > > command not found > > - rebuilt for new gcc4.1 snapshot and glibc changes > > HIH debugging > > gianluca Thanks. The bug should be fixed now. -- Dennis From orion at cora.nwra.com Fri Feb 10 21:40:46 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 10 Feb 2006 14:40:46 -0700 Subject: Today's anaconda refuses to partition my disk Message-ID: ks: bootloader --location=mbr clearpart --linux --drives=hda part /boot --fstype ext3 --size=50 part pv.1 --size 4800 --grow volgroup rootvg pv.1 logvol / --vgname=rootvg --size=512 --name=root logvol swap --fstype=swap --vgname=rootvg --recommended --name=swap logvol /usr --vgname=rootvg --size=4000 --name=usr logvol /var --vgname=rootvg --size=256 --name=var logvol /export/data1 --vgname=rootvg --size=1 --name=data1 --grow anaconda.log: 14:33:57 DEBUG : self.driveList(): ['hda'] 14:33:57 DEBUG : DiskSet.skippedDisks: [] 14:33:57 DEBUG : DiskSet.skippedDisks: [] 14:33:57 DEBUG : starting all dmraids on drives ['hda'] 14:33:57 DEBUG : scanning for dmraid on drives ['hda'] 14:33:58 WARNING : Requested resolution 1600x1200 is not supported, falling back to 800x6 00. To avoid this you may need to specify the videocard and monitor specs on the xconfig ks directive if they were not probed correctly. 14:33:58 INFO : Detected 2032M of memory 14:33:58 INFO : Swap attempt of 1000M to 2000M 14:33:58 WARNING : step partitionmethod does not exist 14:33:58 WARNING : step partitionmethodsetup does not exist 14:33:58 WARNING : step autopartition does not exist 14:33:58 WARNING : step readcomps does not exist 14:33:58 WARNING : step selectlangpackages does not exist 14:33:58 WARNING : step handleX11pkgs does not exist 14:33:58 WARNING : step handlemiscpkgs does not exist 14:33:58 WARNING : step fixupconditionals does not exist 14:33:58 WARNING : step complete does not exist 14:33:58 WARNING : step complete does not exist 14:33:58 WARNING : step complete does not exist 14:33:58 WARNING : step complete does not exist 14:33:58 WARNING : step complete does not exist 14:33:58 WARNING : step complete does not exist 14:33:58 WARNING : step complete does not exist 14:33:58 INFO : moving (1) to step partitionobjinit 14:33:58 DEBUG : self.driveList(): ['hda'] 14:33:58 DEBUG : DiskSet.skippedDisks: [] 14:33:58 DEBUG : DiskSet.skippedDisks: [] 14:33:58 INFO : moving (1) to step autopartitionexecute 14:33:59 DEBUG : self.driveList(): ['hda'] 14:33:59 DEBUG : DiskSet.skippedDisks: [] 14:33:59 DEBUG : DiskSet.skippedDisks: [] From seandarcy2 at gmail.com Sat Feb 11 23:08:39 2006 From: seandarcy2 at gmail.com (sean) Date: Sat, 11 Feb 2006 18:08:39 -0500 Subject: rawhide report: 20060209 changes (part 1/2) In-Reply-To: <200602091507.k19F7p2g012345@porkchop.devel.redhat.com> References: <200602091507.k19F7p2g012345@porkchop.devel.redhat.com> Message-ID: Build System wrote: ............ > foomatic-3.0.2-33.1 > ------------------- > * Tue Feb 07 2006 Jesse Keating - 3.0.2-33.1 > - rebuilt for new gcc4.1 snapshot and glibc changes > ........... foomatic update just hung. Finally ^c'd it: Updating : foomatic ################### [ 281/2235] error: %post(foomatic-3.0.2-33.1.x86_64) scriptlet failed, signal 2 sean From seandarcy2 at gmail.com Sun Feb 12 01:52:49 2006 From: seandarcy2 at gmail.com (sean) Date: Sat, 11 Feb 2006 20:52:49 -0500 Subject: rawhide report: 20060209 changes (part 1/2) In-Reply-To: References: <200602091507.k19F7p2g012345@porkchop.devel.redhat.com> Message-ID: sean wrote: > Build System wrote: > ............ > >> foomatic-3.0.2-33.1 >> ------------------- >> * Tue Feb 07 2006 Jesse Keating - 3.0.2-33.1 >> - rebuilt for new gcc4.1 snapshot and glibc changes >> > ........... > > foomatic update just hung. Finally ^c'd it: > > Updating : foomatic ################### [ 281/2235] > error: %post(foomatic-3.0.2-33.1.x86_64) scriptlet failed, signal 2 > > sean > This didn't cause a hang ( and therefore no dups ) but: Installing: gnome-volume-manager ################### [ 762/1664] error: unpacking of archive failed on file /usr/bin/magicdev: cpio: rename ............ sean From russell at coker.com.au Sun Feb 12 07:39:20 2006 From: russell at coker.com.au (Russell Coker) Date: Sun, 12 Feb 2006 18:39:20 +1100 Subject: auid In-Reply-To: <20060209182343.37733.qmail@web51513.mail.yahoo.com> References: <20060209182343.37733.qmail@web51513.mail.yahoo.com> Message-ID: <200602121839.29087.russell@coker.com.au> On Friday 10 February 2006 05:23, Steve G wrote: > >That might break any alternatives to these programs, e.g. from Fedora > >Extras, such as proftpd, wouldn't it? > > Proftpd has never been modified (by us) to set the loginuid. Not that it > can't be done...it just hasn't. Steve, I think that Paul interpreted your message to mean that only vsftpd would be permitted to change the auid while other ftp daemons would not. Paul, the way these things work is that we (generally) have all daemons that perform a particular service running with the same security context. Therefore if vsftpd is permitted to change the auid then proftpd will also be permitted to do that. As Steve points out someone has to write the 10 line patch to proftpd to make it do so (and we have no immediate plans to do so). If anyone wants to contribute some code for this then it would be appreciated. -- 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 jfontain at free.fr Sun Feb 12 15:03:12 2006 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Sun, 12 Feb 2006 16:03:12 +0100 Subject: %fedora_useradd: which UID can I use? Message-ID: <43EF4E30.8080904@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As documented in http://fedoraproject.org/wiki/Packaging/UserCreation, I am planning to use %fedora_useradd in the spec file for moomps (already in Extras). Is there an authority to assign a unique UID for that package? Many thanks in advance, - -- Jean-Luc Fontaine http://jfontain.free.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFD704vkG/MMvcT1qQRAsqKAKCM3KA3UmQCuRakF6Zk1dzAIsRT9QCghY7y GzGReUaL4EYZ1f1K0Ns/NxQ= =YKZH -----END PGP SIGNATURE----- From linux_4ever at yahoo.com Sun Feb 12 15:04:07 2006 From: linux_4ever at yahoo.com (Steve G) Date: Sun, 12 Feb 2006 07:04:07 -0800 (PST) Subject: auid In-Reply-To: <200602121839.29087.russell@coker.com.au> Message-ID: <20060212150407.79127.qmail@web51512.mail.yahoo.com> >As Steve points out someone has to write the 10 line patch to proftpd to make it >do so (and we have no immediate plans to do so). vsftpd gets it via pam. When you add pam_loginuid.so to the pam stack for the session, it automatically does it. We are being very careful to add it to just the right programs. The criteria is that the program must be an entry point to the system (login, sshd, vsftptd) or does something on behalf of a user (cron, at). If anyone does patch other entry point daemons, please send an email to either fedora-selinux, linux-audit, or fedora-devel mail list so that we know it's been done. It sometimes requires selinux policy adjustments to work properly. Thanks, -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From eric.tanguy at univ-nantes.fr Sun Feb 12 15:55:30 2006 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Sun, 12 Feb 2006 16:55:30 +0100 Subject: %fedora_useradd: which UID can I use? In-Reply-To: <43EF4E30.8080904@free.fr> References: <43EF4E30.8080904@free.fr> Message-ID: <1139759730.3106.6.camel@bureau.maison> Le dimanche 12 f?vrier 2006 ? 16:03 +0100, Jean-Luc Fontaine a ?crit : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > As documented in > http://fedoraproject.org/wiki/Packaging/UserCreation, I am planning to > use %fedora_useradd in the spec file for moomps (already in Extras). > Is there an authority to assign a unique UID for that package? > > Many thanks in advance, > > - -- > Jean-Luc Fontaine http://jfontain.free.fr/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFD704vkG/MMvcT1qQRAsqKAKCM3KA3UmQCuRakF6Zk1dzAIsRT9QCghY7y > GzGReUaL4EYZ1f1K0Ns/NxQ= > =YKZH > -----END PGP SIGNATURE----- > No just add it yourself using a non used one : http://fedoraproject.org/wiki/Packaging/UserRegistry Eric From jfontain at free.fr Sun Feb 12 17:34:34 2006 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Sun, 12 Feb 2006 18:34:34 +0100 Subject: %fedora_useradd: which UID can I use? In-Reply-To: <1139759730.3106.6.camel@bureau.maison> References: <43EF4E30.8080904@free.fr> <1139759730.3106.6.camel@bureau.maison> Message-ID: <43EF71AA.6090800@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Tanguy wrote: > Le dimanche 12 f?vrier 2006 ? 16:03 +0100, Jean-Luc Fontaine a > ?crit : > > As documented in > http://fedoraproject.org/wiki/Packaging/UserCreation, I am planning > to use %fedora_useradd in the spec file for moomps (already in > Extras). Is there an authority to assign a unique UID for that > package? > > Many thanks in advance, > > No just add it yourself using a non used one : > http://fedoraproject.org/wiki/Packaging/UserRegistry Done. Thank you very much, - -- Jean-Luc Fontaine http://jfontain.free.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFD73GqkG/MMvcT1qQRAgNvAJ4muibNd+/9A9qDBp+wIKwu19S1UACfeNj4 1sXUj2bPYB6AT4fiZLu+ggE= =0EDR -----END PGP SIGNATURE----- From mailinglists at erwinrol.com Sun Feb 12 17:43:24 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sun, 12 Feb 2006 18:43:24 +0100 Subject: openldap runuser Message-ID: <1139766204.15597.1.camel@xpc.home.erwinrol.com> Hey all, I am trying to get openldap running, but when i start it i get the following error: [root at xpc etc]# /etc/init.d/ldap start Checking configuration files for slapd: /sbin/runuser: invalid option -- u Try `/sbin/runuser --help' for more information. [FAILED] Is this a real bug in the init script, or am i just doing something wrong ? - Erwin From fenlason at redhat.com Sun Feb 12 19:52:12 2006 From: fenlason at redhat.com (Jay Fenlason) Date: Sun, 12 Feb 2006 14:52:12 -0500 Subject: openldap runuser In-Reply-To: <1139766204.15597.1.camel@xpc.home.erwinrol.com> References: <1139766204.15597.1.camel@xpc.home.erwinrol.com> Message-ID: <20060212195212.GA8069@redhat.com> On Sun, Feb 12, 2006 at 06:43:24PM +0100, Erwin Rol wrote: > Hey all, > > I am trying to get openldap running, but when i start it i get the > following error: > > [root at xpc etc]# /etc/init.d/ldap start > Checking configuration files for slapd: /sbin/runuser: invalid option -- u > Try `/sbin/runuser --help' for more information. > [FAILED] > > Is this a real bug in the init script, or am i just doing something wrong ? It's a bug. I tried to fix it, but it's still not working right. I'll push through a new OpenLDAP after the current mass rebuild is done. -- JF From felipe.alfaro at gmail.com Sun Feb 12 19:54:20 2006 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Sun, 12 Feb 2006 20:54:20 +0100 Subject: openldap runuser In-Reply-To: <20060212195212.GA8069@redhat.com> References: <1139766204.15597.1.camel@xpc.home.erwinrol.com> <20060212195212.GA8069@redhat.com> Message-ID: <6f6293f10602121154w205db98ah641a8e1f7dec983d@mail.gmail.com> > > [root at xpc etc]# /etc/init.d/ldap start > > Checking configuration files for slapd: /sbin/runuser: invalid option -- u > > Try `/sbin/runuser --help' for more information. > > [FAILED] > > > > Is this a real bug in the init script, or am i just doing something wrong ? > > It's a bug. I tried to fix it, but it's still not working right. > I'll push through a new OpenLDAP after the current mass rebuild is > done. A workaround is to disable SELinux (at least, it worked for me). From mailinglists at erwinrol.com Sun Feb 12 20:02:30 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sun, 12 Feb 2006 21:02:30 +0100 Subject: openldap runuser In-Reply-To: <20060212195212.GA8069@redhat.com> References: <1139766204.15597.1.camel@xpc.home.erwinrol.com> <20060212195212.GA8069@redhat.com> Message-ID: <1139774550.17385.1.camel@xpc.home.erwinrol.com> On Sun, 2006-02-12 at 14:52 -0500, Jay Fenlason wrote: > On Sun, Feb 12, 2006 at 06:43:24PM +0100, Erwin Rol wrote: > It's a bug. I tried to fix it, but it's still not working right. > I'll push through a new OpenLDAP after the current mass rebuild is > done. Is there a simple work around ? Or could you mail the new init scripts. - Erwin From mailinglists at erwinrol.com Sun Feb 12 20:03:17 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sun, 12 Feb 2006 21:03:17 +0100 Subject: openldap runuser In-Reply-To: <6f6293f10602121154w205db98ah641a8e1f7dec983d@mail.gmail.com> References: <1139766204.15597.1.camel@xpc.home.erwinrol.com> <20060212195212.GA8069@redhat.com> <6f6293f10602121154w205db98ah641a8e1f7dec983d@mail.gmail.com> Message-ID: <1139774597.17385.3.camel@xpc.home.erwinrol.com> On Sun, 2006-02-12 at 20:54 +0100, Felipe Alfaro Solana wrote: > > > > It's a bug. I tried to fix it, but it's still not working right. > > I'll push through a new OpenLDAP after the current mass rebuild is > > done. > > A workaround is to disable SELinux (at least, it worked for me). Hmmm i have selinux disabled already, so that doesn't look like a workaround for me :-) - Erwin From felipe.alfaro at gmail.com Sun Feb 12 20:26:06 2006 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Sun, 12 Feb 2006 21:26:06 +0100 Subject: openldap runuser In-Reply-To: <1139774597.17385.3.camel@xpc.home.erwinrol.com> References: <1139766204.15597.1.camel@xpc.home.erwinrol.com> <20060212195212.GA8069@redhat.com> <6f6293f10602121154w205db98ah641a8e1f7dec983d@mail.gmail.com> <1139774597.17385.3.camel@xpc.home.erwinrol.com> Message-ID: <6f6293f10602121226w5272d666o7a10ee1778ae9d2f@mail.gmail.com> > > A workaround is to disable SELinux (at least, it worked for me). > > Hmmm i have selinux disabled already, so that doesn't look like a > workaround for me :-) Strange... did you boot with "selinux=0" kernel boot parameter appended to the kernel command line? From mailinglists at erwinrol.com Sun Feb 12 20:31:54 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sun, 12 Feb 2006 21:31:54 +0100 Subject: openldap runuser In-Reply-To: <6f6293f10602121226w5272d666o7a10ee1778ae9d2f@mail.gmail.com> References: <1139766204.15597.1.camel@xpc.home.erwinrol.com> <20060212195212.GA8069@redhat.com> <6f6293f10602121154w205db98ah641a8e1f7dec983d@mail.gmail.com> <1139774597.17385.3.camel@xpc.home.erwinrol.com> <6f6293f10602121226w5272d666o7a10ee1778ae9d2f@mail.gmail.com> Message-ID: <1139776314.17385.5.camel@xpc.home.erwinrol.com> On Sun, 2006-02-12 at 21:26 +0100, Felipe Alfaro Solana wrote: > > > A workaround is to disable SELinux (at least, it worked for me). > > > > Hmmm i have selinux disabled already, so that doesn't look like a > > workaround for me :-) > > Strange... did you boot with "selinux=0" kernel boot parameter > appended to the kernel command line? Yep since there was this trouble with selinux breaking some weeks ago, ever since i have a selinux=0 in my grub.conf. - Erwin From mailinglists at erwinrol.com Sun Feb 12 23:10:41 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Mon, 13 Feb 2006 00:10:41 +0100 Subject: apache and phpldapconfig Message-ID: <1139785841.17385.25.camel@xpc.home.erwinrol.com> I am trying to get phpldapconfig working and i have the following problem. when loading the phpldapconfig page everything works fine, my "local host" ldap server shows up, and i can click on "login". When i do that i get the login "prompt" and fill out my login data, than press enter or click the button, and than something strange happens, I get a file save dialog asking me if i want to save login.php. If i check my apache error_log i see that apache died with a sig 11. does anybody else have this problem ? - Erwin [Mon Feb 13 00:05:36 2006] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Mon Feb 13 00:05:36 2006] [info] Init: Seeding PRNG with 256 bytes of entropy [Mon Feb 13 00:05:36 2006] [info] Init: Generating temporary RSA private keys (512/1024 bits) [Mon Feb 13 00:05:37 2006] [info] Init: Generating temporary DH parameters (512/1024 bits) [Mon Feb 13 00:05:37 2006] [info] Init: Initializing (virtual) servers for SSL [Mon Feb 13 00:05:37 2006] [info] Server: Apache/2.2.0, Interface: mod_ssl/2.2.0, Library: OpenSSL/0.9.8a [Mon Feb 13 00:05:37 2006] [notice] Digest: generating secret for digest authentication ... [Mon Feb 13 00:05:37 2006] [notice] Digest: done [Mon Feb 13 00:05:37 2006] [debug] util_ldap.c(1873): LDAP merging Shared Cache conf: shm=0x5555557a4258 rmm=0x5555557a4290 for VHOST: xpc.home.erwinrol.com [Mon Feb 13 00:05:37 2006] [info] APR LDAP: Built with OpenLDAP LDAP SDK [Mon Feb 13 00:05:37 2006] [info] LDAP: SSL support available [Mon Feb 13 00:05:37 2006] [info] Init: Seeding PRNG with 256 bytes of entropy [Mon Feb 13 00:05:37 2006] [info] Init: Generating temporary RSA private keys (512/1024 bits) [Mon Feb 13 00:05:37 2006] [info] Init: Generating temporary DH parameters (512/1024 bits) [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(369): shmcb_init allocated 512000 bytes of shared memory [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(549): entered shmcb_init_memory() [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(571): for 512000 bytes, recommending 4265 indexes [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(614): shmcb_init_memory choices follow [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(616): division_mask = 0x1F [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(618): division_offset = 96 [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(620): division_size = 15997 [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(622): queue_size = 2136 [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(624): index_num = 133 [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(626): index_offset = 8 [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(628): index_size = 16 [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(630): cache_data_offset = 8 [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(632): cache_data_size = 13853 [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(645): leaving shmcb_init_memory() [Mon Feb 13 00:05:37 2006] [info] Shared memory session cache initialised [Mon Feb 13 00:05:37 2006] [info] Init: Initializing (virtual) servers for SSL [Mon Feb 13 00:05:37 2006] [info] Server: Apache/2.2.0, Interface: mod_ssl/2.2.0, Library: OpenSSL/0.9.8a [Mon Feb 13 00:05:37 2006] [debug] proxy_util.c(1681): proxy: initialized single connection worker 0 in child 22171 for (*) [Mon Feb 13 00:05:37 2006] [notice] Apache/2.2.0 (Fedora) configured -- resuming normal operations [Mon Feb 13 00:05:37 2006] [info] Server built: Feb 8 2006 03:09:46 [Mon Feb 13 00:05:37 2006] [debug] prefork.c(991): AcceptMutex: sysvsem (default: sysvsem) [Mon Feb 13 00:05:58 2006] [notice] child pid 22175 exit signal Segmentation fault (11) From michael at knox.net.nz Mon Feb 13 02:03:48 2006 From: michael at knox.net.nz (Michael J Knox) Date: Mon, 13 Feb 2006 15:03:48 +1300 Subject: snort inline on Fedora Message-ID: <1139796228.25720.9.camel@cosima.et.endace.com> Hi all, Having some issues packaging up snort (and its many different builds). Snort with in-line functionality does not build at all. I get the errors that are reported (but un-actioned and reported on FC3) in bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168045 and also in the in-line FAQ: http://snort-inline.sourceforge.net/FAQ.html The suggestion is to point to a set of "real" kernel includes instead of RH's glibc-kernheaders package. However, whilst this may work for a one of build, its not elegant for a mass deployment of snort installs via rpm. Has anyone got some suggestions on what should be done about this or how to work around it (from a packaging standpoint) ? Thanks in advance. Michael From rodd at clarkson.id.au Mon Feb 13 02:25:31 2006 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Mon, 13 Feb 2006 13:25:31 +1100 Subject: Weird placement of some new window when dragging others Message-ID: <1139797531.3337.4.camel@localhost.localdomain> I've noticed this for some time now, but haven't been able to lock down an solid example, but let me describe so that I can see if others have seen this too and then I'll bugzilla it. When I open a new window in Gnome, if it appears when I'm dragging another window then if often appears with the title bar at the same height as the window I'm dragging. For example, open an evolution window (by default it's fairly large on my system) and do nothing an it will always appear with the entire window visible. Now, open a gnome-terminal window, then a evolution window (do evolution --force-shutdown first to make sure it takes a moment to appear) and then drag the gnome-terminal window around the bottom of the screen. Often the evolution window will appear with the title bar at the same height as the title bar of the gnome-terminal windows I'm dragging and some of the evolution window off the bottom of the screen. I've seen this with gedit, gnome-terminal and other windows and this is both dragging them or having them as the new window. Something seems a little 'wiggy' with regard to placement in Metacity. Have others seen this? Rodd -- "It's a fine line between denial and faith. It's much better on my side" From shezanbaig2004 at gmail.com Mon Feb 13 04:12:38 2006 From: shezanbaig2004 at gmail.com (S Baig) Date: Sun, 12 Feb 2006 23:12:38 -0500 Subject: gnome-power-manager quits unexpectedly Message-ID: <4b3752c70602122012n73a21d1bic65b6c926247f8db@mail.gmail.com> Hi, I just installed Fedora5 Test2 and when I log into Gnome, I immediately get a message box saying "The Application "gnome-power-manager" has quit unexpectedly". Then I open a terminal and try running 'gnome-power-manager' from the command prompt, I get the same message box, but also the following text is printed on the terminal: ** (gnome-power-manager:6362): WARNING **: main: Unable to determine the address of the message bus ** ERROR **: This program cannot start until you start the dbus session daemon This is usually started in X or gnome startup (depending on distro) You can launch the session dbus-daemon manually with this command: eval `dbus-launch --auto-syntax` I cannot find 'dbus-launch' anywhere in my path, but I verified using 'system-config-services' that the messagebus service is running. Has anyone else had this problem? Thanks, -shez- -------------- next part -------------- An HTML attachment was scrubbed... URL: From arjan at fenrus.demon.nl Mon Feb 13 07:37:38 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Mon, 13 Feb 2006 08:37:38 +0100 Subject: snort inline on Fedora In-Reply-To: <1139796228.25720.9.camel@cosima.et.endace.com> References: <1139796228.25720.9.camel@cosima.et.endace.com> Message-ID: <1139816258.2997.12.camel@laptopd505.fenrus.org> On Mon, 2006-02-13 at 15:03 +1300, Michael J Knox wrote: > Hi all, > > Having some issues packaging up snort (and its many different builds). > > Snort with in-line functionality does not build at all. I get the errors > that are reported (but un-actioned and reported on FC3) in bugzilla: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168045 and also in > the in-line FAQ: http://snort-inline.sourceforge.net/FAQ.html > > The suggestion is to point to a set of "real" kernel includes instead of > RH's glibc-kernheaders package. it's a problem in that apparently snort wants to use kernel internal headers.... which is wrong on so many levels it's not funny. That or snort "forgets" to include dependent headers... if you include kernel headers (even derived cleaned up ones like in glibc-kernheaders) you need to know what you're doing... From michael at knox.net.nz Mon Feb 13 07:39:25 2006 From: michael at knox.net.nz (Michael J Knox) Date: Mon, 13 Feb 2006 20:39:25 +1300 Subject: snort inline on Fedora In-Reply-To: <1139816258.2997.12.camel@laptopd505.fenrus.org> References: <1139796228.25720.9.camel@cosima.et.endace.com> <1139816258.2997.12.camel@laptopd505.fenrus.org> Message-ID: <1139816365.2681.0.camel@pingu.homenetwork.lan> On Mon, 2006-02-13 at 08:37 +0100, Arjan van de Ven wrote: > On Mon, 2006-02-13 at 15:03 +1300, Michael J Knox wrote: > > Hi all, > > > > Having some issues packaging up snort (and its many different builds). > > > > Snort with in-line functionality does not build at all. I get the errors > > that are reported (but un-actioned and reported on FC3) in bugzilla: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168045 and also in > > the in-line FAQ: http://snort-inline.sourceforge.net/FAQ.html > > > > The suggestion is to point to a set of "real" kernel includes instead of > > RH's glibc-kernheaders package. > > > it's a problem in that apparently snort wants to use kernel internal > headers.... which is wrong on so many levels it's not funny. > That or snort "forgets" to include dependent headers... if you include > kernel headers (even derived cleaned up ones like in glibc-kernheaders) > you need to know what you're doing... > So what would be the best way to "fix" this? Michael From seg at haxxed.com Mon Feb 13 07:52:02 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 13 Feb 2006 01:52:02 -0600 Subject: auid In-Reply-To: <200602092233.35511.russell@coker.com.au> References: <200602092233.35511.russell@coker.com.au> Message-ID: <1139817122.8577.5.camel@localhost> On Thu, 2006-02-09 at 22:33 +1100, Russell Coker wrote: > Of course this gives the problem of what happens when you restart sshd or > crond, those programs would then be unable to set the auid. In Fedora we > have gdm started from init, so restarting gdm is possible without auid issues > in this regard. As we have the precedent with this daemon (which > incidentally most other distributions seem to start from an /etc/init.d > script) it doesn't seem unreasonable to me for "sshd -D" to also be run from > init, and modifying crond to also support a -D option would not be difficult. This is absolutely horrible. Its bad enough I have to switch run levels just to shut down gdm, the last thing we need is more daemons run from init. So, about that FCNewInit 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 arjan at fenrus.demon.nl Mon Feb 13 07:45:53 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Mon, 13 Feb 2006 08:45:53 +0100 Subject: snort inline on Fedora In-Reply-To: <1139816365.2681.0.camel@pingu.homenetwork.lan> References: <1139796228.25720.9.camel@cosima.et.endace.com> <1139816258.2997.12.camel@laptopd505.fenrus.org> <1139816365.2681.0.camel@pingu.homenetwork.lan> Message-ID: <1139816754.2997.16.camel@laptopd505.fenrus.org> > > So what would be the best way to "fix" this? the latest snort just compiles for me... so maybe use that? From michael at knox.net.nz Mon Feb 13 07:47:55 2006 From: michael at knox.net.nz (Michael J Knox) Date: Mon, 13 Feb 2006 20:47:55 +1300 Subject: snort inline on Fedora In-Reply-To: <1139816754.2997.16.camel@laptopd505.fenrus.org> References: <1139796228.25720.9.camel@cosima.et.endace.com> <1139816258.2997.12.camel@laptopd505.fenrus.org> <1139816365.2681.0.camel@pingu.homenetwork.lan> <1139816754.2997.16.camel@laptopd505.fenrus.org> Message-ID: <1139816875.2681.2.camel@pingu.homenetwork.lan> On Mon, 2006-02-13 at 08:45 +0100, Arjan van de Ven wrote: > > > > So what would be the best way to "fix" this? > > > the latest snort just compiles for me... so maybe use that? > Checking it out now. thanks! Michael From buildsys at redhat.com Mon Feb 13 07:48:26 2006 From: buildsys at redhat.com (Build System) Date: Mon, 13 Feb 2006 02:48:26 -0500 Subject: rawhide report: 20060213 changes 2/2 Message-ID: <200602130748.k1D7mQKs019059@porkchop.devel.redhat.com> mysql-5.0.18-2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 5.0.18-2.1 - bump again for double-long bug on ppc(64) * Thu Feb 09 2006 Tom Lane 5.0.18-2 - err-log option has been renamed to log-error, fix my.cnf and initscript * Tue Feb 07 2006 Jesse Keating - 5.0.18-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes mysql-connector-odbc-3.51.12-1.2.1 ---------------------------------- * Fri Feb 10 2006 Jesse Keating - 3.51.12-1.2.1 - bump again for double-long bug on ppc(64) mysqlclient10-3.23.58-9.2 ------------------------- * Fri Feb 10 2006 Jesse Keating - 3.23.58-9.2 - bump again for double-long bug on ppc(64) mysqlclient14-4.1.14-4.2 ------------------------ * Fri Feb 10 2006 Jesse Keating - 4.1.14-4.2 - bump again for double-long bug on ppc(64) nano-1.3.8-1.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.3.8-1.2.1 - bump again for double-long bug on ppc(64) nasm-0.98.39-3.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 0.98.39-3.2.1 - bump again for double-long bug on ppc(64) nautilus-2.13.90-2.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 2.13.90-2.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 2.13.90-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Mon Feb 06 2006 Matthias Clasen - 2.13.90-2 - Avoid delays in rendering the background nautilus-cd-burner-2.13.90-1.2 ------------------------------ * Fri Feb 10 2006 Jesse Keating - 2.13.90-1.2 - bump again for double-long bug on ppc(64) nautilus-sendto-0.4-7.2 ----------------------- * Fri Feb 10 2006 Jesse Keating - 0.4-7.2 - bump again for double-long bug on ppc(64) nc-1.84-3.2 ----------- * Fri Feb 10 2006 Jesse Keating - 1.84-3.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 1.84-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Wed Jan 25 2006 Radek Vokal 1.84-3 - warnings cleaned-up, compile with -Werror ncompress-4.2.4-43.2.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 4.2.4-43.2.1 - bump again for double-long bug on ppc(64) ncpfs-2.2.6-1.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 2.2.6-1.2.1 - bump again for double-long bug on ppc(64) ncurses-5.5-18.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 5.5-18.2 - bump again for double-long bug on ppc(64) neon-0.25.5-1.2 --------------- * Fri Feb 10 2006 Jesse Keating - 0.25.5-1.2 - bump again for double-long bug on ppc(64) net-snmp-5.3-4.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 5.3-4.2 - bump again for double-long bug on ppc(64) net-tools-1.60-62.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 1.60-62.1 - bump again for double-long bug on ppc(64) * Fri Feb 10 2006 Radek Vok??l - 1.60-62 - new option for netstat - -T stops trimming remote and local addresses (#176465) netatalk-4:2.0.3-4.2.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 4:2.0.3-4.2.1 - bump again for double-long bug on ppc(64) netdump-0.7.14-1.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 0.7.14-1.2.1 - bump again for double-long bug on ppc(64) netpbm-10.31-3.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 10.31-3.1 - bump again for double-long bug on ppc(64) * Fri Feb 10 2006 Jindrich Novy 10.31-3 - fix segfault caused by usage of uninitialized variables while parsing cmdline arguments in pnmtopng (#179645) - add validity check for date/time in pnmtopng - fix unchecked sscanf reads newt-0.52.2-5.2 --------------- * Fri Feb 10 2006 Jesse Keating - 0.52.2-5.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 0.52.2-5.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Tue Jan 17 2006 Petr Rockai - 0.52.2-5 - Fix a crash in checkboxtree.c where pressing pgup/pgdown on a checkboxtree with less items than its height would cause segmentation violation. Consult BR 165347. newt-perl-1.08-9.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 1.08-9.2.1 - bump again for double-long bug on ppc(64) nfs-utils-1.0.8.rc2-4.FC5.2 --------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.8.rc2-4.FC5.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 1.0.8.rc2-4.FC5.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Jan 20 2006 Steve Dickson 1.0.8.rc2-4.FC5 - Added new libnfsidmap call, nfs4_set_debug(), to rpc.idmapd which turns on debugging in the libarary. nfs-utils-lib-1.0.8-3.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.8-3.1 - bump again for double-long bug on ppc(64) nhpf-1.42-9.2.1 --------------- * Fri Feb 10 2006 Jesse Keating - 1.42-9.2.1 - bump again for double-long bug on ppc(64) nkf-2.05-1.2.1 -------------- * Fri Feb 10 2006 Jesse Keating - 2.05-1.2.1 - bump again for double-long bug on ppc(64) nmap-2:4.00-1.2 --------------- * Fri Feb 10 2006 Jesse Keating - 2:4.00-1.2 - bump again for double-long bug on ppc(64) notify-daemon-0.3.1-7.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 0.3.1-7.1 - bump again for double-long bug on ppc(64) nspr-4.6.1-2.2 -------------- * Fri Feb 10 2006 Jesse Keating - 4.6.1-2.2 - bump again for double-long bug on ppc(64) nss-3.11-3.2 ------------ * Fri Feb 10 2006 Jesse Keating - 3.11-3.2 - bump again for double-long bug on ppc(64) nss_db-2.2-34.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 2.2-34.2.1 - bump again for double-long bug on ppc(64) nss_ldap-248-2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 248-2.1 - bump again for double-long bug on ppc(64) ntp-4.2.0.a.20050816-10.2.1 --------------------------- * Fri Feb 10 2006 Jesse Keating - 4.2.0.a.20050816-10.2.1 - bump again for double-long bug on ppc(64) numactl-0.6.4-1.26.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 0.6.4-1.25.2 - bump again for double-long bug on ppc(64) nut-2.0.2-6.2 ------------- * Fri Feb 10 2006 Jesse Keating - 2.0.2-6.2 - bump again for double-long bug on ppc(64) oaf-0.6.10-12.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 0.6.10-12.2.1 - bump again for double-long bug on ppc(64) opal-2.1-1.2 ------------ open-1.4-24.2.1 --------------- * Fri Feb 10 2006 Jesse Keating - 1.4-24.2.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 1.4-24.2 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 09 2005 Jesse Keating - rebuilt openhpi-2.2.1-4.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 2.2.1-4.2 - bump again for double-long bug on ppc(64) openjade-1.3.2-23.2 ------------------- * Fri Feb 10 2006 Jesse Keating - 1.3.2-23.2 - bump again for double-long bug on ppc(64) openldap-2.3.19-3.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 2.3.19-3.1 - bump again for double-long bug on ppc(64) openmotif-2.3.0-0.1.9.2 ----------------------- * Fri Feb 10 2006 Jesse Keating - 2.3.0-0.1.9.2 - bump again for double-long bug on ppc(64) openobex-1.0.1-4.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1-4.2.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 1.0.1-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 09 2005 Jesse Keating - rebuilt openobex-apps-1.0.0-8.2.1 ------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0-8.2.1 - bump again for double-long bug on ppc(64) openoffice.org-1:2.0.1.1-11.2.2 ------------------------------- * Fri Feb 10 2006 Jesse Keating - 1:2.0.1.1-11.2.2 - bump again for double-long bug on ppc(64) opensm-1.0-0.4265.1.FC5.2.1 --------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0-0.4265.1.FC5.2.1 - bump again for double-long bug on ppc(64) opensp-1.5.2-1.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.5.2-1.2 - bump again for double-long bug on ppc(64) openssh-4.3p1-2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 4.3p1-2.1 - bump again for double-long bug on ppc(64) openssl-0.9.8a-5.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 0.9.8a-5.2 - bump again for double-long bug on ppc(64) openssl097a-0.9.7a-4.2.1 ------------------------ * Fri Feb 10 2006 Jesse Keating - 0.9.7a-4.2.1 - bump again for double-long bug on ppc(64) openswan-2.4.4-1.1.2.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 2.4.4-1.1.2.1 - bump again for double-long bug on ppc(64) oprofile-0.9.1-8.1.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 0.9.1-8.1.1 - bump again for double-long bug on ppc(64) * Fri Feb 10 2006 Will Cohen - Complete path for which and dirname in opcontrol. pam-0.99.3.0-1.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 0.99.3.0-1.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 0.99.3.0-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Feb 03 2006 Tomas Mraz 0.99.3.0-1 - new upstream version - updated db4 to 4.3.29 - added module pam_tally2 with auditing support - added manual pages for system-auth and config-util (#179584) pam_ccreds-3-3.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 3-3.2 - bump again for double-long bug on ppc(64) pam_passwdqc-1.0.2-1.2.1 ------------------------ * Fri Feb 10 2006 Jesse Keating - 1.0.2-1.2.1 - bump again for double-long bug on ppc(64) pam_smb-1.1.7-7.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 1.1.7-7.2 - bump again for double-long bug on ppc(64) pango-1.11.5-1 -------------- * Sat Feb 11 2006 Matthias Clasen - 1.11.5-1 - Update to 1.11.5 * Fri Feb 10 2006 Jesse Keating - 1.11.4-1.2 - bump again for double-long bug on ppc(64) parted-1.6.25-6.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 1.6.25-6.1 - bump again for double-long bug on ppc(64) passwd-0.71-3.2 --------------- * Fri Feb 10 2006 Jesse Keating - 0.71-3.2 - bump again for double-long bug on ppc(64) patch-2.5.4-29.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 2.5.4-29.2.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 2.5.4-29.2 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 09 2005 Jesse Keating - rebuilt patchutils-0.2.31-2.2.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 0.2.31-2.2.1 - bump again for double-long bug on ppc(64) pax-3.4-1.2.1 ------------- * Fri Feb 10 2006 Jesse Keating - 3.4-1.2.1 - bump again for double-long bug on ppc(64) pciutils-2.2.1-1.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 2.2.1-1.2 - bump again for double-long bug on ppc(64) pcmciautils-011-1.2 ------------------- * Fri Feb 10 2006 Jesse Keating - 011-1.2 - bump again for double-long bug on ppc(64) pcre-6.3-1.2.1 -------------- * Fri Feb 10 2006 Jesse Keating - 6.3-1.2.1 - bump again for double-long bug on ppc(64) perl-4:5.8.8-2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 4:5.8.8-2.1 - bump again for double-long bug on ppc(64) * Fri Feb 10 2006 Jason Vas Dias - 4:5.8.8-2 - Rebuild again - Debian released 5.8.8 patches today; apply only relevant difference: 03_fix_net_nntp : fix precedence in Net::NNTP::article from Brendan O'Dea * Mon Feb 06 2006 Jason Vas Dias - 4:5.8.8-1.2 - Rebuild with new gcc, glibc, and glibc-kernheaders perl-BSD-Resource-1.24-3.2.2 ---------------------------- * Fri Feb 10 2006 Jesse Keating - 1.24-3.2.2 - bump again for double-long bug on ppc(64) perl-Bit-Vector-6.4-2.2.2 ------------------------- * Fri Feb 10 2006 Jesse Keating - 6.4-2.2.2 - bump again for double-long bug on ppc(64) perl-Compress-Zlib-1.41-1.2.2 ----------------------------- * Fri Feb 10 2006 Jesse Keating - 1.41-1.2.2 - bump again for double-long bug on ppc(64) perl-Crypt-SSLeay-0.51-9.2.2 ---------------------------- * Fri Feb 10 2006 Jesse Keating - 0.51-9.2.2 - bump again for double-long bug on ppc(64) perl-DBD-MySQL-3.0002-2.2.2 --------------------------- * Fri Feb 10 2006 Jesse Keating - 3.0002-2.2.2 - bump again for double-long bug on ppc(64) perl-DBD-Pg-1.43-2.2.2 ---------------------- * Fri Feb 10 2006 Jesse Keating - 1.43-2.2.2 - bump again for double-long bug on ppc(64) perl-DBI-1.50-2.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 1.50-2.2 - bump again for double-long bug on ppc(64) perl-Date-Calc-5.4-1.2.2 ------------------------ * Fri Feb 10 2006 Jesse Keating - 5.4-1.2.2 - bump again for double-long bug on ppc(64) perl-Digest-SHA1-2.11-1.2 ------------------------- * Fri Feb 10 2006 Jesse Keating - 2.11-1.2 - bump again for double-long bug on ppc(64) perl-HTML-Parser-3.48-1.1.2 --------------------------- * Fri Feb 10 2006 Jesse Keating - 3.48-1.1.2 - bump again for double-long bug on ppc(64) perl-Net-DNS-0.55-1.1.2 ----------------------- * Fri Feb 10 2006 Jesse Keating - 0.55-1.1.2 - bump again for double-long bug on ppc(64) perl-PDL-2.4.2-2.fc5.1.2.2 -------------------------- * Fri Feb 10 2006 Jesse Keating - 2.4.2-2.fc5.1.2.2 - bump again for double-long bug on ppc(64) perl-String-CRC32-1.3-3.FC5.2 ----------------------------- * Fri Feb 10 2006 Jesse Keating - 1.3-3.FC5.2 - bump again for double-long bug on ppc(64) perl-TermReadKey-2.30-1.2.2 --------------------------- * Fri Feb 10 2006 Jesse Keating - 2.30-1.2.2 - bump again for double-long bug on ppc(64) perl-XML-LibXML-1.58-2.2.2 -------------------------- * Fri Feb 10 2006 Jesse Keating - 1.58-2.2.2 - bump again for double-long bug on ppc(64) perl-XML-LibXML-Common-0.13-8.2.1 --------------------------------- * Fri Feb 10 2006 Jesse Keating - 0.13-8.2.1 - bump again for double-long bug on ppc(64) perl-XML-Parser-2.34-6.1.2.2 ---------------------------- * Fri Feb 10 2006 Jesse Keating - 2.34-6.1.2.2 - bump again for double-long bug on ppc(64) php-5.1.2-4.3 ------------- * Fri Feb 10 2006 Jesse Keating - 5.1.2-4.3 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 5.1.2-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Tue Jan 31 2006 Joe Orton 5.1.2-4 - rebuild for new libc-client soname pilot-link-1:0.12.0-0.pre4.5.2.1 -------------------------------- * Fri Feb 10 2006 Jesse Keating - 1:0.12.0-0.pre4.5.2.1 - bump again for double-long bug on ppc(64) pinfo-0.6.8-11.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 0.6.8-11.2.1 - bump again for double-long bug on ppc(64) pkgconfig-1:0.20-2.2.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 1:0.20-2.2.1 - bump again for double-long bug on ppc(64) planner-0.13-4.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 0.13-4.1 - bump again for double-long bug on ppc(64) pm-utils-0.09-1.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 0.09-1.2 - bump again for double-long bug on ppc(64) pnm2ppa-1:1.04-13.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 1:1.04-13.2.1 - bump again for double-long bug on ppc(64) policycoreutils-1.29.20-2.1 --------------------------- * Fri Feb 10 2006 Jesse Keating - 1.29.20-2.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Dan Walsh 1.29.20-2 - Fix auditing to semanage - Change genhomedircon to use new prefix interface in libselinux poppler-0.5.0-4.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 0.5.0-4.2 - bump again for double-long bug on ppc(64) portmap-4.0-65.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 4.0-65.2.1 - bump again for double-long bug on ppc(64) postfix-2:2.2.8-1.2 ------------------- * Fri Feb 10 2006 Jesse Keating - 2:2.2.8-1.2 - bump again for double-long bug on ppc(64) postgresql-odbc-08.01.0200-1.2 ------------------------------ * Fri Feb 10 2006 Jesse Keating - 08.01.0200-1.2 - bump again for double-long bug on ppc(64) ppc64-utils-0.9-12.2.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 0.9-12.2.1 - bump again for double-long bug on ppc(64) ppp-2.4.3-6.2.1 --------------- * Fri Feb 10 2006 Jesse Keating - 2.4.3-6.2.1 - bump again for double-long bug on ppc(64) privoxy-3.0.3-9.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 3.0.3-9.2.1 - bump again for double-long bug on ppc(64) procinfo-18-18.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 18-18.2.1 - bump again for double-long bug on ppc(64) procmail-3.22-16.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 3.22-16.2.1 - bump again for double-long bug on ppc(64) procps-3.2.6-3.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 3.2.6-3.2 - bump again for double-long bug on ppc(64) psacct-6.3.2-38.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 6.3.2-38.2 - bump again for double-long bug on ppc(64) psmisc-21.8-1.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 21.8-1.2.1 - bump again for double-long bug on ppc(64) pstack-1.2-7.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.2-7.2.1 - bump again for double-long bug on ppc(64) psutils-1.17-25.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 1.17-25.2.1 - bump again for double-long bug on ppc(64) pump-0.8.24-1.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 0.8.24-1.2.1 - bump again for double-long bug on ppc(64) pvm-3.4.5-6.7.1 --------------- * Fri Feb 10 2006 Jesse Keating - 3.4.5-6.7.1 - bump again for double-long bug on ppc(64) pwlib-1.9.2-1.2 --------------- * Fri Feb 10 2006 Jesse Keating - 1.9.2-1.2 - bump again for double-long bug on ppc(64) pyOpenSSL-0.6-1.p24.7.2.1 ------------------------- * Fri Feb 10 2006 Jesse Keating - 0.6-1.p24.7.2.1 - bump again for double-long bug on ppc(64) pycairo-1.0.2-1.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.2-1.2.1 - bump again for double-long bug on ppc(64) pyorbit-2.0.1-4.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 2.0.1-4.2.1 - bump again for double-long bug on ppc(64) pyparted-1.6.10-1.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 1.6.10-1.2.1 - bump again for double-long bug on ppc(64) python-2.4.2-3.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 2.4.2-3.2.1 - bump again for double-long bug on ppc(64) * Fri Feb 10 2006 Mihai Ibanescu - 2.4.3-3.2 - rebuilt for newer tix * Tue Feb 07 2006 Jesse Keating - 2.4.2-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes python-elementtree-1.2.6-4.2.1 ------------------------------ * Fri Feb 10 2006 Jesse Keating - 1.2.6-4.2.1 - bump again for double-long bug on ppc(64) python-ldap-0:2.0.6-5.2.1 ------------------------- * Fri Feb 10 2006 Jesse Keating - 0:2.0.6-5.2.1 - bump again for double-long bug on ppc(64) python-numeric-23.7-2.2.1 ------------------------- * Fri Feb 10 2006 Jesse Keating - 23.7-2.2.1 - bump again for double-long bug on ppc(64) python-pyblock-0.13-1.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 0.13-1.1 - bump again for double-long bug on ppc(64) python-sqlite-1.1.7-1.2 ----------------------- * Fri Feb 10 2006 Jesse Keating - 1.1.7-1.2 - bump again for double-long bug on ppc(64) qt-1:3.3.5-12.2 --------------- * Fri Feb 10 2006 Jesse Keating - 1:3.3.5-12.2 - bump again for double-long bug on ppc(64) quagga-0:0.98.5-3.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 0:0.98.5-3.2.1 - bump again for double-long bug on ppc(64) quota-1:3.13-1.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 1:3.13-1.2.1 - bump again for double-long bug on ppc(64) radvd-0.9.1-1.1.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 0.9.1-1.1.1 - bump again for double-long bug on ppc(64) rarpd-ss981107-22.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - ss981107-22.2.1 - bump again for double-long bug on ppc(64) rcs-5.7-29.2.1 -------------- * Fri Feb 10 2006 Jesse Keating - 5.7-29.2.1 - bump again for double-long bug on ppc(64) rdate-1.4-4.2.1 --------------- * Fri Feb 10 2006 Jesse Keating - 1.4-4.2.1 - bump again for double-long bug on ppc(64) rdesktop-1.4.1-3.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 1.4.1-3.2.1 - bump again for double-long bug on ppc(64) rdist-1:6.1.5-42.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 1:6.1.5-42.2.1 - bump again for double-long bug on ppc(64) readahead-1:1.2-1.25.2 ---------------------- * Fri Feb 10 2006 Jesse Keating - 1:1.2-1.24.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 1:1.2-1.23.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Jan 13 2006 Karel Zak - check & cleanup list of files by readahead-gen script readline-5.0-3.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 5.0-3.2.1 - bump again for double-long bug on ppc(64) redhat-artwork-0.238-1.1 ------------------------ * Fri Feb 10 2006 Jesse Keating - 0.238-1.1 - bump again for double-long bug on ppc(64) redhat-lsb-3.0-9.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 3.0-9.2 - bump again for double-long bug on ppc(64) regexp-0:1.3-2jpp_6fc --------------------- * Fri Feb 10 2006 Jesse Keating - 0:1.3-2jpp_6fc - bump again for double-long bug on ppc(64) rhdb-utils-8.1.1-1.2.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 8.1.1-1.2.1 - bump again for double-long bug on ppc(64) rhgb-0.16.2-21.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 0.16.2-21.2 - bump again for double-long bug on ppc(64) rhn-applet-2.1.17-4.2.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 2.1.17-4.2.1 - bump again for double-long bug on ppc(64) rhpl-0.181-2.1 -------------- * Fri Feb 10 2006 Jesse Keating - 0.181-2.1 - bump again for double-long bug on ppc(64) rhythmbox-0.9.3.1-1.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 0.9.3.1-1.2 - bump again for double-long bug on ppc(64) rp-pppoe-3.5-30.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 3.5-30.2.1 - bump again for double-long bug on ppc(64) rpm-4.4.2-15.2 -------------- * Fri Feb 10 2006 Jesse Keating - 4.4.2-15.2 - bump again for double-long bug on ppc(64) rsh-0.17-34.1 ------------- * Fri Feb 10 2006 Jesse Keating - 0.17-34.1 - bump again for double-long bug on ppc(64) rsync-2.6.6-2.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 2.6.6-2.2.1 - bump again for double-long bug on ppc(64) ruby-1.8.4-3.2 -------------- * Fri Feb 10 2006 Jesse Keating - 1.8.4-3.2 - bump again for double-long bug on ppc(64) rusers-0.17-45.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 0.17-45.2.1 - bump again for double-long bug on ppc(64) rwall-0.17-25.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 0.17-25.2.1 - bump again for double-long bug on ppc(64) rwho-0.17-25.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 0.17-25.2.1 - bump again for double-long bug on ppc(64) samba-0:3.0.20b-2.1.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 0:3.0.20b-2.1.1 - bump again for double-long bug on ppc(64) sane-backends-1.0.17-3.2 ------------------------ * Fri Feb 10 2006 Jesse Keating - 1.0.17-3.2 - bump again for double-long bug on ppc(64) sane-frontends-1.0.14-1.2.1 --------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.14-1.2.1 - bump again for double-long bug on ppc(64) scim-1.4.4-4.1 -------------- * Fri Feb 10 2006 Jesse Keating - 1.4.4-4.1 - bump again for double-long bug on ppc(64) * Fri Feb 10 2006 Jens Petersen - 1.4.4-4 - parse the libstdc++so7 datestamp from the wrapper script * Thu Feb 09 2006 Jens Petersen - 1.4.4-3 - build conditionally with libstdc++so7 preview to workround libstdc++ weak symbol version conflicts for c++ gtk apps built with older gcc (Benjamin Kosnik, #166041) - add with_libstdc_preview switch and tweak libtool to link against newer lib - do not change scim_binary_version in scim.pc-versioned-moduledir-179706.patch - set qtimm to xim for now scim-anthy-0.9.0-2.fc5.1 ------------------------ * Fri Feb 10 2006 Jesse Keating - 0.9.0-2.fc5.1 - bump again for double-long bug on ppc(64) * Thu Feb 09 2006 Jens Petersen - list .so modules explicitly in filelist scim-chewing-0.2.1-5.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 0.2.1-5.1 - bump again for double-long bug on ppc(64) scim-hangul-0.2.1-3.fc5.1 ------------------------- * Fri Feb 10 2006 Jesse Keating - 0.2.1-3.fc5.1 - bump again for double-long bug on ppc(64) scim-m17n-0.2.0-1 ----------------- * Sun Feb 12 2006 Jens Petersen - 0.2.0-1 - update to 0.2.0 release * Fri Feb 10 2006 Jesse Keating - 0.1.4-3.1 - bump again for double-long bug on ppc(64) scim-pinyin-0.5.91-4.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 0.5.91-4.1 - bump again for double-long bug on ppc(64) scim-qtimm-0.9.4-2.1.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 0.9.4-2.1.1 - bump again for double-long bug on ppc(64) scim-tables-0.5.6-2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 0.5.6-2.1 - bump again for double-long bug on ppc(64) screen-4.0.2-11.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 4.0.2-11.2 - bump again for double-long bug on ppc(64) scrollkeeper-0.3.14-5.2.1 ------------------------- * Fri Feb 10 2006 Jesse Keating - 0.3.14-5.2.1 - bump again for double-long bug on ppc(64) sed-4.1.5-1.2 ------------- * Fri Feb 10 2006 Jesse Keating - 4.1.5-1.2 - bump again for double-long bug on ppc(64) selinux-policy-2.2.13-1 ----------------------- * Fri Feb 10 2006 Dan Walsh 2.2.13-1 - Add semodule policy sendmail-8.13.5-2.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 8.13.5-2.2.1 - bump again for double-long bug on ppc(64) setarch-1.8-1.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 1.8-1.2.1 - bump again for double-long bug on ppc(64) setools-2.3-1.2 --------------- * Fri Feb 10 2006 Jesse Keating - 2.3-1.2 - bump again for double-long bug on ppc(64) setserial-2.17-19.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 2.17-19.2.1 - bump again for double-long bug on ppc(64) setuptool-1.18.1-1.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 1.18.1-1.2 - bump again for double-long bug on ppc(64) sg3_utils-1.19-1.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 1.19-1.1 - bump again for double-long bug on ppc(64) * Fri Feb 10 2006 Phil Knirsch - 1.19-1 - Update to sg3_utils-1.19. - Fixed rebuild problem on 64bit archs. * Tue Feb 07 2006 Jesse Keating - 1.17-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes shadow-utils-2:4.0.14-1.2 ------------------------- * Fri Feb 10 2006 Jesse Keating - 2:4.0.14-1.2 - bump again for double-long bug on ppc(64) shared-mime-info-0.16.cvs20060212-1 ----------------------------------- * Sun Feb 12 2006 Christopher Aillon - 0.16.cvs20060212-1 - Newer CVS snapshot sharutils-4.6.1-1.2 ------------------- * Fri Feb 10 2006 Jesse Keating - 4.6.1-1.2 - bump again for double-long bug on ppc(64) sip-4.3.1-1.2.1 --------------- * Fri Feb 10 2006 Jesse Keating - 4.3.1-1.2.1 - bump again for double-long bug on ppc(64) slang-2.0.5-5.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 2.0.5-5.2.1 - bump again for double-long bug on ppc(64) slrn-0.9.8.1pl1-1.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 0.9.8.1pl1-1.2.1 - bump again for double-long bug on ppc(64) smartmontools-1:5.33-4.2 ------------------------ * Fri Feb 10 2006 Jesse Keating - 1:5.33-4.2 - bump again for double-long bug on ppc(64) sound-juicer-2.13.5-1 --------------------- * Sun Feb 12 2006 Matthias Clasen - 2.13.5-1 - Update to 2.13.5 * Fri Feb 10 2006 Jesse Keating - 2.13.4-3.2 - bump again for double-long bug on ppc(64) sox-12.17.9-1.2 --------------- * Fri Feb 10 2006 Jesse Keating - 12.17.9-1.2 - bump again for double-long bug on ppc(64) spamassassin-3.1.0-5.fc5.2 -------------------------- * Fri Feb 10 2006 Jesse Keating - 3.1.0-5.fc5.2 - bump again for double-long bug on ppc(64) speex-1.0.5-1.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 1.0.5-1.2.1 - bump again for double-long bug on ppc(64) sqlite-3.3.3-1.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 3.3.3-1.2 - bump again for double-long bug on ppc(64) squashfs-tools-2.2r2-2.2.1 -------------------------- * Fri Feb 10 2006 Jesse Keating - 2.2r2-2.2.1 - bump again for double-long bug on ppc(64) squid-7:2.5.STABLE12-5.1 ------------------------ * Fri Feb 10 2006 Jesse Keating - 7:2.5.STABLE12-5.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Martin Stransky - 7:2.5.STABLE12-5 - new upstream patches star-1.5a69-1.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 1.5a69-1.2.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 1.5a69-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 09 2005 Jesse Keating - rebuilt stardict-2.4.5-2.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 2.4.5-2.2 - bump again for double-long bug on ppc(64) startup-notification-0.8-3.2.1 ------------------------------ * Fri Feb 10 2006 Jesse Keating - 0.8-3.2.1 - bump again for double-long bug on ppc(64) statserial-1.1-38.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 1.1-38.2.1 - bump again for double-long bug on ppc(64) strace-4.5.14-1.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 4.5.14-1.2 - bump again for double-long bug on ppc(64) struts-0:1.2.4-2jpp_7fc ----------------------- * Fri Feb 10 2006 Jesse Keating - 0:1.2.4-2jpp_7fc - bump again for double-long bug on ppc(64) stunnel-4.14-3.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 4.14-3.2 - bump again for double-long bug on ppc(64) subversion-1.3.0-4.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 1.3.0-4.2 - bump again for double-long bug on ppc(64) sudo-1.6.8p12-4.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 1.6.8p12-4.1 - bump again for double-long bug on ppc(64) swig-1.3.24-2.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 1.3.24-2.2.1 - bump again for double-long bug on ppc(64) symlinks-1.2-24.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 1.2-24.2.1 - bump again for double-long bug on ppc(64) synaptics-0:0.14.4-4.2.1 ------------------------ * Fri Feb 10 2006 Jesse Keating - 0:0.14.4-4.2.1 - bump again for double-long bug on ppc(64) sysfsutils-1.3.0-1.2.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 1.3.0-1.2.1 - bump again for double-long bug on ppc(64) sysklogd-1.4.1-34.2 ------------------- * Fri Feb 10 2006 Jesse Keating - 1.4.1-34.2 - bump again for double-long bug on ppc(64) sysstat-6.0.1-3.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 6.0.1-3.2.1 - bump again for double-long bug on ppc(64) system-config-lvm-1.0.13-1.0 ---------------------------- * Fri Feb 10 2006 Stanko Kupcevic 1.0.13-1.0 - Fix failure to display all unused space system-config-printer-0.6.150-1.2 --------------------------------- * Fri Feb 10 2006 Jesse Keating - 0.6.150-1.2 - bump again for double-long bug on ppc(64) system-config-securitylevel-1.6.15-1.1 -------------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.6.15-1.1 - bump again for double-long bug on ppc(64) systemtap-0.5.4-2.2 ------------------- * Fri Feb 10 2006 Jesse Keating - 0.5.4-2.2 - bump again for double-long bug on ppc(64) talk-0.17-29.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 0.17-29.2.1 - bump again for double-long bug on ppc(64) tanukiwrapper-0:3.1.1-4jpp_6fc ------------------------------ * Fri Feb 10 2006 Jesse Keating - 0:3.1.1-4jpp_6fc - bump again for double-long bug on ppc(64) tar-1.15.1-12.2 --------------- * Fri Feb 10 2006 Jesse Keating - 1.15.1-12.2 - bump again for double-long bug on ppc(64) tcl-8.4.12-3.2 -------------- * Fri Feb 10 2006 Jesse Keating - 8.4.12-3.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 8.4.12-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Thu Feb 02 2006 David Cantrell - 8.4.12-3 - Patched syntax errors in configure and tcl.m4 so it works with bash tclx-8.4.0-1.2 -------------- * Fri Feb 10 2006 Jesse Keating - 8.4.0-1.2 - bump again for double-long bug on ppc(64) tcp_wrappers-7.6-40.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 7.6-40.2 - bump again for double-long bug on ppc(64) tcpdump-14:3.9.4-2.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 14:3.9.4-2.2 - bump again for double-long bug on ppc(64) tcsh-6.14-5.2.1 --------------- * Fri Feb 10 2006 Jesse Keating - 6.14-5.2.1 - bump again for double-long bug on ppc(64) telnet-1:0.17-35.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 1:0.17-35.2.1 - bump again for double-long bug on ppc(64) tetex-3.0-16.2 -------------- * Fri Feb 10 2006 Jesse Keating - 3.0-16.2 - bump again for double-long bug on ppc(64) texinfo-4.8-9.2 --------------- * Fri Feb 10 2006 Jesse Keating - 4.8-9.2 - bump again for double-long bug on ppc(64) tftp-0.41-1.2.1 --------------- * Fri Feb 10 2006 Jesse Keating - 0.41-1.2.1 - bump again for double-long bug on ppc(64) thunderbird-0:1.5-3 ------------------- * Fri Feb 10 2006 Christopher Aillon - 1.5-3 - Add dumpstack.patch - Improve the langpack install stuff * Tue Feb 07 2006 Jesse Keating - 1.5-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes time-1.7-27.2.1 --------------- * Fri Feb 10 2006 Jesse Keating - 1.7-27.2.1 - bump again for double-long bug on ppc(64) timidity++-2.13.2-1.2.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 2.13.2-1.2.1 - bump again for double-long bug on ppc(64) tix-1:8.4.0-3.1 --------------- * Fri Feb 10 2006 Jesse Keating - 1:8.4.0-3.1 - bump again for double-long bug on ppc(64) * Fri Feb 10 2006 David Cantrell - 1:8.4.0-3 - Added missing SONAME to libTix8.4.so tk-8.4.12-1.2 ------------- * Fri Feb 10 2006 Jesse Keating - 8.4.12-1.2 - bump again for double-long bug on ppc(64) tmpwatch-2.9.6-1.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 2.9.6-1.2.1 - bump again for double-long bug on ppc(64) tn5250-0.17.3-1.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 0.17.3-1.2.1 - bump again for double-long bug on ppc(64) tog-pegasus-2:2.5-6.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 2:2.5-6.1 - bump again for double-long bug on ppc(64) tomcat5-0:5.0.30-8jpp_11fc -------------------------- * Fri Feb 10 2006 Jesse Keating - 0:5.0.30-8jpp_10fc - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 0:5.0.30-8jpp_9fc.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Wed Feb 01 2006 Rafael Schloming - 0:5.0.30-8jpp_9fc - Fixed XSS vulnerabilities in the example apps. totem-1.3.90-2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.3.90-2.1 - bump again for double-long bug on ppc(64) traceroute-2:1.0.4-1.2 ---------------------- * Fri Feb 10 2006 Jesse Keating - 2:1.0.4-1.2 - bump again for double-long bug on ppc(64) transfig-1:3.2.4-13.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 1:3.2.4-13.2 - bump again for double-long bug on ppc(64) tree-1.5.0-3.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.5.0-3.2.1 - bump again for double-long bug on ppc(64) tsclient-0.140-1.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 0.140-1.2.1 - bump again for double-long bug on ppc(64) ttcp-1.12-13.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.12-13.2.1 - bump again for double-long bug on ppc(64) ttmkfdir-3.0.9-19.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 3.0.9-19.2.1 - bump again for double-long bug on ppc(64) tux-3.2.18-4.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 3.2.18-4.2.1 - bump again for double-long bug on ppc(64) tvtime-1.0.1-3.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1-3.2 - bump again for double-long bug on ppc(64) udev-084-1.1 ------------ * Fri Feb 10 2006 Jesse Keating - 084-1.1 - bump again for double-long bug on ppc(64) umb-scheme-3.2-39.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 3.2-39.2.1 - bump again for double-long bug on ppc(64) units-1.85-1.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.85-1.2.1 - bump again for double-long bug on ppc(64) unix2dos-2.2-26.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 2.2-26.2.1 - bump again for double-long bug on ppc(64) unixODBC-2.2.11-6.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 2.2.11-6.2.1 - bump again for double-long bug on ppc(64) unzip-5.52-2.2 -------------- * Fri Feb 10 2006 Jesse Keating - 5.52-2.2 - bump again for double-long bug on ppc(64) up2date-4.4.23-4.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 4.4.23-4.2.1 - bump again for double-long bug on ppc(64) usbutils-0.71-1.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 0.71-1.2 - bump again for double-long bug on ppc(64) usermode-1.85-2.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 1.85-2.2 - bump again for double-long bug on ppc(64) utempter-0.5.5-7.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 0.5.5-7.2.1 - bump again for double-long bug on ppc(64) util-linux-2.13-0.15.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 2.13-0.15.1 - bump again for double-long bug on ppc(64) uucp-1.07-11.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.07-11.2.1 - bump again for double-long bug on ppc(64) valgrind-1:3.1.0-1.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 1:3.1.0-1.2 - bump again for double-long bug on ppc(64) vconfig-1.9-1.1 --------------- * Fri Feb 10 2006 Jesse Keating - 1.9-1.1 - bump again for double-long bug on ppc(64) * Fri Feb 10 2006 Phil Knirsch - 1.9-1 - Updated to vconfig-1.9 vim-1:6.4.006-1.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 1:6.4.006-1.2 - bump again for double-long bug on ppc(64) vino-2.13.5-2.2 --------------- * Fri Feb 10 2006 Jesse Keating - 2.13.5-2.2 - bump again for double-long bug on ppc(64) vixie-cron-4:4.1-51.FC5.1 ------------------------- * Fri Feb 10 2006 Jesse Keating - 4:4.1-51.FC5.1 - bump again for double-long bug on ppc(64) vlock-1.3-22.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.3-22.2.1 - bump again for double-long bug on ppc(64) vnc-4.1.1-35.1 -------------- * Fri Feb 10 2006 Jesse Keating - 4.1.1-35.1 - bump again for double-long bug on ppc(64) vorbis-tools-1:1.1.1-1.2.1 -------------------------- * Fri Feb 10 2006 Jesse Keating - 1:1.1.1-1.2.1 - bump again for double-long bug on ppc(64) vsftpd-2.0.4-1.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 2.0.4-1.2 - bump again for double-long bug on ppc(64) vte-0.11.18-1.fc5.1 ------------------- * Sat Feb 11 2006 Matthias Clasen 0.11.18-1 - Update to 0.11.18 * Fri Feb 10 2006 Jesse Keating - 0.11.17-1.fc5.1.2 - bump again for double-long bug on ppc(64) w3m-0.5.1-12.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 0.5.1-12.2.1 - bump again for double-long bug on ppc(64) webalizer-2.01_10-29.2.1 ------------------------ * Fri Feb 10 2006 Jesse Keating - 2.01_10-29.2.1 - bump again for double-long bug on ppc(64) wget-1.10.2-3.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 1.10.2-3.2.1 - bump again for double-long bug on ppc(64) which-2.16-6.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 2.16-6.2.1 - bump again for double-long bug on ppc(64) wireless-tools-1:28-0.pre13.5.1 ------------------------------- * Sun Feb 12 2006 Christopher Aillon - 1:28-0.pre13.5.1 - Update to 28 pre13 wordtrans-1.1pre13-12.2.1 ------------------------- * Fri Feb 10 2006 Jesse Keating - 1.1pre13-12.2.1 - bump again for double-long bug on ppc(64) wpa_supplicant-0.5.1-3 ---------------------- * Sun Feb 12 2006 Dan Williams - 0.5.1-3 - Documentation cleanup (Terje Rosten ) * Sun Feb 12 2006 Dan Williams - 0.5.1-2 - Move initscript to /etc/rc.d/init.d * Fri Feb 10 2006 Jesse Keating - 0.5.1-1.2 - bump again for double-long bug on ppc(64) wvdial-1.54.0-5.2.2 ------------------- * Fri Feb 10 2006 Jesse Keating - 1.54.0-5.2.2 - bump again for double-long bug on ppc(64) xalan-j2-0:2.6.0-3jpp_8fc ------------------------- * Fri Feb 10 2006 Jesse Keating - 0:2.6.0-3jpp_8fc - bump again for double-long bug on ppc(64) xcdroast-0.98a15-12.2.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 0.98a15-12.2.1 - bump again for double-long bug on ppc(64) xdelta-1.1.3-17.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 1.1.3-17.2.1 - bump again for double-long bug on ppc(64) xerces-j2-0:2.6.2-6jpp_5fc -------------------------- * Fri Feb 10 2006 Jesse Keating - 0:2.6.2-6jpp_5fc - bump again for double-long bug on ppc(64) xferstats-2.16-13.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 2.16-13.2.1 - bump again for double-long bug on ppc(64) xfig-3.2.4-17.2 --------------- * Fri Feb 10 2006 Jesse Keating - 3.2.4-17.2 - bump again for double-long bug on ppc(64) xfsprogs-2.7.3-1.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 2.7.3-1.2.1 - bump again for double-long bug on ppc(64) xinetd-2:2.3.13-6.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 2:2.3.13-6.2.1 - bump again for double-long bug on ppc(64) xml-commons-0:1.0-0.b2.7jpp_5fc ------------------------------- * Fri Feb 10 2006 Jesse Keating - 0:1.0-0.b2.7jpp_5fc - bump again for double-long bug on ppc(64) xmlrpc-0:2.0.1-1jpp_4fc ----------------------- * Fri Feb 10 2006 Jesse Keating - 0:2.0.1-1jpp_4fc - bump again for double-long bug on ppc(64) xmlsec1-1.2.9-4.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 1.2.9-4.2 - bump again for double-long bug on ppc(64) xmlto-0.0.18-9.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 0.0.18-9.2.1 - bump again for double-long bug on ppc(64) xorg-x11-apps-1.0.1-1.2 ----------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-acecad-1.0.0.5-1.2 ------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-aiptek-1.0.0.5-1.2 ------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-ati-6.5.7.3-3.2 ---------------------------- * Fri Feb 10 2006 Jesse Keating - 6.5.7.3-3.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-calcomp-1.0.0.5-1.2 -------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-citron-2.1.1.5-1.2 ------------------------------- * Fri Feb 10 2006 Jesse Keating - 2.1.1.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-digitaledge-1.0.1.3-1.2 ------------------------------------ * Fri Feb 10 2006 Jesse Keating - 1.0.1.3-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-dmc-1.0.0.5-1.2 ---------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-dummy-0.1.0.5-1.2 ------------------------------ * Fri Feb 10 2006 Jesse Keating - 0.1.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-dynapro-1.0.0.5-1.2 -------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-elo2300-1.0.0.5-1.2 -------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-elographics-1.0.0.5-1.2 ------------------------------------ * Fri Feb 10 2006 Jesse Keating - 1.0.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-evdev-1.0.0.5-1.2 ------------------------------ * Fri Feb 10 2006 Jesse Keating - 1.0.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-fbdev-0.1.0.5-1.2 ------------------------------ * Fri Feb 10 2006 Jesse Keating - 0.1.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-fpit-1.0.0.5-1.2 ----------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-hyperpen-1.0.0.5-1.2 --------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-jamstudio-1.0.0.5-1.2 ---------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-joystick-1.0.0.5-1.2 --------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-keyboard-1.0.1.3-1.2 --------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1.3-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-magellan-1.0.0.5-1.2 --------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-magictouch-1.0.0.5-1.2 ----------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-mga-1.2.1.3-1.2 ---------------------------- * Fri Feb 10 2006 Jesse Keating - 1.2.1.3-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-microtouch-1.0.0.5-1.2 ----------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-mouse-1.0.3.1-1.2 ------------------------------ * Fri Feb 10 2006 Jesse Keating - 1.0.3.1-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-mutouch-1.0.0.5-1.2 -------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-nv-1.0.1.5-3.1 --------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1.5-3.1 - bump again for double-long bug on ppc(64) xorg-x11-drv-palmax-1.0.0.5-1.2 ------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-penmount-1.0.0.5-1.2 --------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-s3-0.3.5.5-1.2 --------------------------- * Fri Feb 10 2006 Jesse Keating - 0.3.5.5-1.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 0.3.5.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Wed Jan 18 2006 Mike A. Harris 0.3.5.5-1 - Updated xorg-x11-drv-s3 to version 0.3.5.5 from X11R7.0 xorg-x11-drv-s3virge-1.8.6.5-1.2 -------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.8.6.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-savage-2.0.2.3-1.2 ------------------------------- * Fri Feb 10 2006 Jesse Keating - 2.0.2.3-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-sis-0.8.1.3-1.2 ---------------------------- * Fri Feb 10 2006 Jesse Keating - 0.8.1.3-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-sisusb-0.7.1.3-1.2 ------------------------------- * Fri Feb 10 2006 Jesse Keating - 0.7.1.3-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-spaceorb-1.0.0.5-1.2 --------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-summa-1.0.0.5-1.2 ------------------------------ * Fri Feb 10 2006 Jesse Keating - 1.0.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-tdfx-1.1.1.3-1.3 ----------------------------- * Fri Feb 10 2006 Jesse Keating - 1.1.1.3-1.3 - bump again for double-long bug on ppc(64) xorg-x11-drv-tek4957-1.0.0.1-1.2 -------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0.1-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-trident-1.0.1.2-1.2 -------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1.2-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-ur98-1.0.0.5-1.2 ----------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-vesa-1.0.1.3-1.2 ----------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1.3-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-vga-4.0.0.5-1.2 ---------------------------- * Fri Feb 10 2006 Jesse Keating - 4.0.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-void-1.0.0.5-1.2 ----------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-drv-voodoo-1.0.0.5-1.2 ------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0.5-1.2 - bump again for double-long bug on ppc(64) xorg-x11-font-utils-1:1.0.1-1.2 ------------------------------- * Fri Feb 10 2006 Jesse Keating - 1:1.0.1-1.2 - bump again for double-long bug on ppc(64) xorg-x11-resutils-1.0.1-1.2 --------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1-1.2 - bump again for double-long bug on ppc(64) xorg-x11-server-1.0.1-6.1 ------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1-6.1 - bump again for double-long bug on ppc(64) xorg-x11-server-utils-1.0.1-1.2 ------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1-1.2 - bump again for double-long bug on ppc(64) xorg-x11-twm-1:1.0.1-1.2 ------------------------ * Fri Feb 10 2006 Jesse Keating - 1:1.0.1-1.2 - bump again for double-long bug on ppc(64) xorg-x11-util-macros-1.0.1-1.2 ------------------------------ * Fri Feb 10 2006 Jesse Keating - 1.0.1-1.2 - bump again for double-long bug on ppc(64) xorg-x11-utils-1.0.1-1.2 ------------------------ * Fri Feb 10 2006 Jesse Keating - 1.0.1-1.2 - bump again for double-long bug on ppc(64) xorg-x11-xauth-1:1.0.1-1.2 -------------------------- * Fri Feb 10 2006 Jesse Keating - 1:1.0.1-1.2 - bump again for double-long bug on ppc(64) xorg-x11-xbitmaps-1.0.1-1.2 --------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1-1.2 - bump again for double-long bug on ppc(64) xorg-x11-xdm-1:1.0.1-1.2 ------------------------ * Fri Feb 10 2006 Jesse Keating - 1:1.0.1-1.2 - bump again for double-long bug on ppc(64) xorg-x11-xfs-1:1.0.1-2.1 ------------------------ * Fri Feb 10 2006 Jesse Keating - 1:1.0.1-2.1 - bump again for double-long bug on ppc(64) xorg-x11-xfwp-1.0.1-1.2 ----------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1-1.2 - bump again for double-long bug on ppc(64) xorg-x11-xinit-1.0.1-1.2 ------------------------ * Fri Feb 10 2006 Jesse Keating - 1.0.1-1.2 - bump again for double-long bug on ppc(64) xorg-x11-xkb-utils-1.0.1-1.2 ---------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1-1.2 - bump again for double-long bug on ppc(64) xorg-x11-xsm-1.0.1-1.2 ---------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1-1.2 - bump again for double-long bug on ppc(64) xorg-x11-xtrans-devel-1.0.0-3.2 ------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0-3.2 - bump again for double-long bug on ppc(64) xpdf-1:3.01-12.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 1:3.01-12.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Than Ngo 3.01-12 - apply patch to fix buffer overflow issue in the xpdf codebase when handling splash images CVE-2006-0301 (#179423) xrestop-0.2-6.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 0.2-6.2.1 - bump again for double-long bug on ppc(64) xsane-0.99-2.2 -------------- * Fri Feb 10 2006 Jesse Keating - 0.99-2.2 - bump again for double-long bug on ppc(64) xscreensaver-1:4.24-1.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 1:4.24-1.1 - bump again for double-long bug on ppc(64) xsri-1:2.1.0-9.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 1:2.1.0-9.2.1 - bump again for double-long bug on ppc(64) xterm-208-1.2 ------------- * Fri Feb 10 2006 Jesse Keating - 208-1.2 - bump again for double-long bug on ppc(64) yaboot-1.3.13-0.17.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 1.3.13-0.17.1 - bump again for double-long bug on ppc(64) yelp-2.13.5-2 ------------- * Sun Feb 12 2006 Matthias Clasen - 2.13.5-2 - Turn on info and man support for test3 * Sun Feb 12 2006 Matthias Clasen - 2.13.5-1 - Update to 2.13.5 * Fri Feb 10 2006 Jesse Keating - 2.13.4-1.2 - bump again for double-long bug on ppc(64) yp-tools-2.8-8.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 2.8-8.2.1 - bump again for double-long bug on ppc(64) ypbind-3:1.17.2-5.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 3:1.17.2-5.2.1 - bump again for double-long bug on ppc(64) ypserv-2.13-10.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 2.13-10.2 - bump again for double-long bug on ppc(64) yum-2.5.1-5 ----------- * Fri Feb 10 2006 Paul Nasrat - 2.5.1-5 - Merge patches from head for group plugin support and conditionals zip-2.31-1.2.1 -------------- * Fri Feb 10 2006 Jesse Keating - 2.31-1.2.1 - bump again for double-long bug on ppc(64) zisofs-tools-1.0.6-3.2.1 ------------------------ * Fri Feb 10 2006 Jesse Keating - 1.0.6-3.2.1 - bump again for double-long bug on ppc(64) zlib-1.2.3-1.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.2.3-1.2.1 - bump again for double-long bug on ppc(64) zsh-4.2.5-1.2.2 --------------- * Fri Feb 10 2006 Jesse Keating - 4.2.5-1.2.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 4.2.5-1.2.2 - rebuilt for new gcc4.1 snapshot and glibc changes * Wed Jan 04 2006 Jesse Keating 0 4.2.5-1.2 - rebuilt again Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 perl-suidperl - 4:5.8.8-2.1.i386 requires perl = 4:5.8.8-2 Broken deps for ia64 ---------------------------------------------------------- perl-suidperl - 4:5.8.8-2.1.ia64 requires perl = 4:5.8.8-2 rgmanager - 1.9.31-3.ia64 requires ccs vconfig - 1.9-1.1.ia64 requires libc.so.6 vconfig - 1.9-1.1.ia64 requires libc.so.6(GLIBC_2.0) Broken deps for ppc ---------------------------------------------------------- ccs-devel - 1.0.2-3.2.1.ppc requires ccs = 0:1.0.2-3.2.1 gulm - 1.0.0-2.ppc requires ccs perl-suidperl - 4:5.8.8-2.1.ppc requires perl = 4:5.8.8-2 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 magma-plugins - 1.0.3-1.FC5.ppc64 requires libgulm.so.1()(64bit) perl-suidperl - 4:5.8.8-2.1.ppc64 requires perl = 4:5.8.8-2 vconfig - 1.9-1.1.ppc64 requires libc.so.6 vconfig - 1.9-1.1.ppc64 requires libc.so.6(GLIBC_2.0) Broken deps for s390 ---------------------------------------------------------- perl-suidperl - 4:5.8.8-2.1.s390 requires perl = 4:5.8.8-2 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 Broken deps for s390x ---------------------------------------------------------- perl-suidperl - 4:5.8.8-2.1.s390x requires perl = 4:5.8.8-2 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 perl-suidperl - 4:5.8.8-2.1.x86_64 requires perl = 4:5.8.8-2 From jkeating at redhat.com Mon Feb 13 07:53:11 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 12 Feb 2006 23:53:11 -0800 Subject: rawhide report: 20060213 changes 2/2 In-Reply-To: <200602130748.k1D7mQKs019059@porkchop.devel.redhat.com> References: <200602130748.k1D7mQKs019059@porkchop.devel.redhat.com> Message-ID: <1139817191.31644.55.camel@ender> On Mon, 2006-02-13 at 02:48 -0500, Build System wrote: > Hrm. So the 1/2 message was still too big for mailman to accept. I'm going to have to split it up even more. Sorry for the uglyness. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-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 Feb 13 07:47:33 2006 From: buildsys at redhat.com (Build System) Date: Mon, 13 Feb 2006 02:47:33 -0500 Subject: rawhide report: 20060213 changes 1/2 Message-ID: <200602130747.k1D7lXGQ018834@porkchop.devel.redhat.com> Removed package gstreamer08-plugins Updated Packages: NetworkManager-0.5.1-11.cvs20060205 ----------------------------------- * Sun Feb 12 2006 Christopher Aillon 0.5.1-11.cvs20060205 - Rebuild * Tue Feb 07 2006 Jesse Keating 0.5.1-10.cvs20060205.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Sun Feb 05 2006 Dan Williams 0.5.1-10.cvs20060205 - Workarounds for madwifi/Atheros cards - Do better with non-SSID-broadcasting access points - Fix hangs when access points change settings a2ps-4.13b-48.3 --------------- * Fri Feb 10 2006 Jesse Keating - 4.13b-48.3 - bump again for double-long bug on ppc(64) acl-2.2.34-1.2 -------------- * Fri Feb 10 2006 Jesse Keating - 2.2.34-1.2 - bump again for double-long bug on ppc(64) adjtimex-1.20-1.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 1.20-1.2.1 - bump again for double-long bug on ppc(64) agg-2.3-2.1 ----------- * Fri Feb 10 2006 Jesse Keating - 2.3-2.1 - bump again for double-long bug on ppc(64) alchemist-1.0.36-1.2.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.36-1.2.1 - bump again for double-long bug on ppc(64) alsa-lib-1.0.11-3.rc2.2 ----------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.11-3.rc2.2 - bump again for double-long bug on ppc(64) alsa-utils-1.0.11-2.rc2.2 ------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.11-2.rc2.2 - bump again for double-long bug on ppc(64) am-utils-5:6.1.3-1.2.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 5:6.1.3-1.2.1 - bump again for double-long bug on ppc(64) amanda-2.4.5p1-3.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 2.4.5p1-3.2 - bump again for double-long bug on ppc(64) amtu-1.0.4-2.2 -------------- * Fri Feb 10 2006 Jesse Keating - 1.0.4-2.2 - bump again for double-long bug on ppc(64) anaconda-10.92.0-1 ------------------ * Sun Feb 12 2006 Jeremy Katz - 10.92.0-1 - Fix length of package name in text install (dcantrel, #180469) - Various minor cleanups - Support conditional packages for langsupport (pnasrat, #178029) anacron-2.3-36.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 2.3-36.1 - bump again for double-long bug on ppc(64) ant-0:1.6.5-1jpp_6fc -------------------- * Fri Feb 10 2006 Jesse Keating - 0:1.6.5-1jpp_6fc - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 0:1.6.5-1jpp_5fc - rebuilt for new gcc4.1 snapshot and glibc changes * Thu Feb 02 2006 Archit Shah - 0:1.6.5-1jpp_4fc - build ant without using native code anthy-7100b-2.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 7100b-2.2.1 - bump again for double-long bug on ppc(64) apr-1.2.2-7.2 ------------- * Fri Feb 10 2006 Jesse Keating - 1.2.2-7.2 - bump again for double-long bug on ppc(64) apr-util-1.2.2-4.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 1.2.2-4.2 - bump again for double-long bug on ppc(64) aqbanking-1.8.1beta-3.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 1.8.1beta-3.1 - bump again for double-long bug on ppc(64) arptables_jf-0:0.0.8-6.2.1 -------------------------- * Fri Feb 10 2006 Jesse Keating - 0:0.0.8-6.2.1 - bump again for double-long bug on ppc(64) arts-8:1.5.1-1.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 8:1.5.1-1.2 - bump again for double-long bug on ppc(64) aspell-12:0.60.3-3.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 12:0.60.3-3.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 12:0.60.3-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Mon Dec 19 2005 Ivana Varekova 12:0.60.3-3 - fix for gcc 4.1 aspell-af-50:0.50-4.2.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 50:0.50-4.2.1 - bump again for double-long bug on ppc(64) aspell-bg-50:0.50-11.2.1 ------------------------ * Fri Feb 10 2006 Jesse Keating - 50:0.50-11.2.1 - bump again for double-long bug on ppc(64) aspell-br-50:0.50-4.2.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 50:0.50-4.2.1 - bump again for double-long bug on ppc(64) aspell-ca-50:0.50-4.2.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 50:0.50-4.2.1 - bump again for double-long bug on ppc(64) aspell-cy-50:0.50-4.2.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 50:0.50-4.2.1 - bump again for double-long bug on ppc(64) aspell-da-50:0.50-12.2.1 ------------------------ * Fri Feb 10 2006 Jesse Keating - 50:0.50-12.2.1 - bump again for double-long bug on ppc(64) aspell-de-50:0.50-11.2.1 ------------------------ * Fri Feb 10 2006 Jesse Keating - 50:0.50-11.2.1 - bump again for double-long bug on ppc(64) aspell-el-50:0.50-4.2.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 50:0.50-4.2.1 - bump again for double-long bug on ppc(64) aspell-en-50:6.0-1.2.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 50:6.0-1.2.1 - bump again for double-long bug on ppc(64) aspell-es-50:0.50-13.2.1 ------------------------ * Fri Feb 10 2006 Jesse Keating - 50:0.50-13.2.1 - bump again for double-long bug on ppc(64) aspell-fo-50:0.51-4.2.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 50:0.51-4.2.1 - bump again for double-long bug on ppc(64) aspell-fr-50:0.50-9.2.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 50:0.50-9.2.1 - bump again for double-long bug on ppc(64) aspell-ga-50:0.50-4.2.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 50:0.50-4.2.1 - bump again for double-long bug on ppc(64) aspell-gd-50:0.50-4.2.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 50:0.50-4.2.1 - bump again for double-long bug on ppc(64) aspell-gl-50:0.50-4.2.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 50:0.50-4.2.1 - bump again for double-long bug on ppc(64) aspell-hr-50:0.51-4.2.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 50:0.51-4.2.1 - bump again for double-long bug on ppc(64) aspell-id-50:0.50.1-4.2.1 ------------------------- * Fri Feb 10 2006 Jesse Keating - 50:0.50.1-4.2.1 - bump again for double-long bug on ppc(64) aspell-is-50:0.51.1-2.2.1 ------------------------- * Fri Feb 10 2006 Jesse Keating - 50:0.51.1-2.2.1 - bump again for double-long bug on ppc(64) aspell-it-50:0.53-4.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 50:0.53-4.2 - bump again for double-long bug on ppc(64) aspell-nl-50:0.50-8.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 50:0.50-8.2 - bump again for double-long bug on ppc(64) aspell-no-50:0.50.1-9.2.1 ------------------------- * Fri Feb 10 2006 Jesse Keating - 50:0.50.1-9.2.1 - bump again for double-long bug on ppc(64) aspell-pl-50:0.51-5.2.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 50:0.51-5.2.1 - bump again for double-long bug on ppc(64) aspell-pt-50:0.50-10.2.1 ------------------------ * Fri Feb 10 2006 Jesse Keating - 50:0.50-10.2.1 - bump again for double-long bug on ppc(64) aspell-ru-50:0.99f7-2.2.1 ------------------------- * Fri Feb 10 2006 Jesse Keating - 50:0.99f7-2.2.1 - bump again for double-long bug on ppc(64) aspell-sl-50:0.50-1.2 --------------------- aspell-sr-50:0.02-1.2 --------------------- aspell-sv-50:0.51-1.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 50:0.51-1.2 - bump again for double-long bug on ppc(64) at-3.1.8-81.1 ------------- * Fri Feb 10 2006 Jesse Keating - 3.1.8-81.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jason Vas Dias - 3.1.8-81 - rebuild for new gcc, glibc, glibc-kernheaders - workaround new refusal of /usr/bin/install to chown * Sun Dec 18 2005 Jason Vas Dias - 3.1.8-80.2 - rebuild for new flex at-spi-1.7.4-1.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.7.4-1.2 - bump again for double-long bug on ppc(64) atk-1.11.2-1.2 -------------- * Fri Feb 10 2006 Jesse Keating - 1.11.2-1.2 - bump again for double-long bug on ppc(64) attr-2.4.28-1.2 --------------- * Fri Feb 10 2006 Jesse Keating - 2.4.28-1.2 - bump again for double-long bug on ppc(64) audiofile-1:0.2.6-2.2.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 1:0.2.6-2.2.1 - bump again for double-long bug on ppc(64) audit-1.1.4-5.1 --------------- * Fri Feb 10 2006 Jesse Keating - 1.1.4-5.1 - bump again for double-long bug on ppc(64) * Fri Feb 10 2006 Steve Grubb 1.1.4-5 - Change audit_log_semanage_message to check strlen as well as NULL. authconfig-5.2.0-1.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 5.2.0-1.2 - bump again for double-long bug on ppc(64) authd-1.4.3-7.1 --------------- * Fri Feb 10 2006 Jesse Keating - 1.4.3-7.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Martin Stransky - 1.4.3-7 - re-tag autofs-1:4.1.4-16.2.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 1:4.1.4-16.2.2 - bump again for double-long bug on ppc(64) autorun-3.18-1.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 3.18-1.2 - bump again for double-long bug on ppc(64) avahi-0.6.6-3.1 --------------- * Fri Feb 10 2006 Jesse Keating - 0.6.6-3.1 - bump again for double-long bug on ppc(64) * Fri Feb 10 2006 Jason Vas Dias - 0.6.6-3 - rebuild for new gcc (again) - further fix for bug 178746: fix avahi-dnsconfd initscript bash-3.1-6.2 ------------ * Fri Feb 10 2006 Jesse Keating - 3.1-6.2 - bump again for double-long bug on ppc(64) bc-1.06-19.2.1 -------------- * Fri Feb 10 2006 Jesse Keating - 1.06-19.2.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 1.06-19.2 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 09 2005 Jesse Keating - rebuilt beagle-0.2.1-3 -------------- * Fri Feb 10 2006 Alexander Larsson - 0.2.1-3 - Correctly allocate uid/gid * Tue Feb 07 2006 Matthias Clasen - 0.2.1-2 - Add missing BuildRequires (#180336) beecrypt-4.1.2-9.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 4.1.2-9.2.1 - bump again for double-long bug on ppc(64) bg5ps-1.3.0-22.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 1.3.0-22.2.1 - bump again for double-long bug on ppc(64) bind-30:9.3.2-4.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 30:9.3.2-4.1 - bump again for double-long bug on ppc(64) binutils-2.16.91.0.5-1.2 ------------------------ * Fri Feb 10 2006 Jesse Keating - 2.16.91.0.5-1.2 - bump again for double-long bug on ppc(64) bison-2.1-1.2.1 --------------- * Fri Feb 10 2006 Jesse Keating - 2.1-1.2.1 - bump again for double-long bug on ppc(64) bluez-hcidump-1.27-1.2.1 ------------------------ * Fri Feb 10 2006 Jesse Keating - 1.27-1.2.1 - bump again for double-long bug on ppc(64) bluez-libs-2.22-1.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 2.22-1.2.1 - bump again for double-long bug on ppc(64) bluez-pin-0.24-3.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 0.24-3.2.1 - bump again for double-long bug on ppc(64) bluez-utils-2.22-2.2.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 2.22-2.2.1 - bump again for double-long bug on ppc(64) bogl-0:0.1.18-11.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 0:0.1.18-11.2.1 - bump again for double-long bug on ppc(64) boost-1.33.1-4.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.33.1-4.2 - bump again for double-long bug on ppc(64) bootparamd-0.17-24.devel.2 -------------------------- * Fri Feb 10 2006 Jesse Keating - 0.17-24.devel.2 - bump again for double-long bug on ppc(64) booty-0.67-1.1 -------------- * Fri Feb 10 2006 Jesse Keating - 0.67-1.1 - bump again for double-long bug on ppc(64) bridge-utils-1.0.6-1.2 ---------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.6-1.2 - bump again for double-long bug on ppc(64) brltty-3.2-10.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 3.2-10.2.1 - bump again for double-long bug on ppc(64) bug-buddy-1:2.13.0-1.2 ---------------------- * Fri Feb 10 2006 Jesse Keating - 1:2.13.0-1.2 - bump again for double-long bug on ppc(64) busybox-1:1.01-2.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 1:1.01-2.2.1 - bump again for double-long bug on ppc(64) byacc-1.9-29.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.9-29.2.1 - bump again for double-long bug on ppc(64) bzip2-1.0.3-2.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 1.0.3-2.2.1 - bump again for double-long bug on ppc(64) cadaver-0.22.3-2.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 0.22.3-2.2 - bump again for double-long bug on ppc(64) cairo-1.0.2-4.2 --------------- * Fri Feb 10 2006 Jesse Keating - 1.0.2-4.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 1.0.2-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Tue Jan 31 2006 Ray Strode 1.0.2-4 - add patch from Tim Mayberry to support embbedded bitmap fonts (bug 176910) cairo-java-1.0.2-0.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.2-0.2 - bump again for double-long bug on ppc(64) ccs-1.0.2-3.2.1 --------------- * Fri Feb 10 2006 Jesse Keating - 1.0.2-3.2.1 - bump again for double-long bug on ppc(64) cdparanoia-alpha9.8-27.1 ------------------------ * Fri Feb 10 2006 Jesse Keating - alpha9.8-27.1 - bump again for double-long bug on ppc(64) cdrdao-1.2.0-1.2.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 1.2.0-1.2.2 - bump again for double-long bug on ppc(64) check-0.9.3-4.fc5.2 ------------------- * Fri Feb 10 2006 Jesse Keating - 0.9.3-4.fc5.2 - bump again for double-long bug on ppc(64) checkpolicy-1.29.1-1.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 1.29.1-1.1 - bump again for double-long bug on ppc(64) chkconfig-1.3.26-1.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 1.3.26-1.2 - bump again for double-long bug on ppc(64) chkfontpath-1.10.0-4.2.1 ------------------------ * Fri Feb 10 2006 Jesse Keating - 1.10.0-4.2.1 - bump again for double-long bug on ppc(64) ckermit-8.0.211-4.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 8.0.211-4.2.1 - bump again for double-long bug on ppc(64) compat-db-4.2.52-3.2.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 4.2.52-3.2.1 - bump again for double-long bug on ppc(64) compat-slang-1.4.9-27.2.1 ------------------------- * Fri Feb 10 2006 Jesse Keating - 1.4.9-27.2.1 - bump again for double-long bug on ppc(64) control-center-1:2.13.91-1.1 ---------------------------- * Fri Feb 10 2006 Jesse Keating - 1:2.13.91-1.1 - bump again for double-long bug on ppc(64) coreutils-5.93-7.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 5.93-7.2 - bump again for double-long bug on ppc(64) cpio-2.6-11.2.1 --------------- * Fri Feb 10 2006 Jesse Keating - 2.6-11.2.1 - bump again for double-long bug on ppc(64) cpufreq-utils-1:0.4-1.1.23 -------------------------- * Sat Feb 11 2006 Dave Jones - rebuild. cpuspeed-1:1.2.1-1.30 --------------------- * Sat Feb 11 2006 Dave Jones - rebuild. cracklib-2.8.6-1.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 2.8.6-1.2.1 - bump again for double-long bug on ppc(64) crypto-utils-2.2-9.2.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 2.2-9.2.1 - bump again for double-long bug on ppc(64) cryptsetup-luks-1.0.1-4.2.1 --------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1-4.2.1 - bump again for double-long bug on ppc(64) cscope-15.5-13.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 15.5-13.2 - bump again for double-long bug on ppc(64) ctags-5.5.4-4.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 5.5.4-4.2.1 - bump again for double-long bug on ppc(64) cups-1:1.1.23-30.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 1:1.1.23-30.2 - bump again for double-long bug on ppc(64) curl-7.15.1-1.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 7.15.1-1.2.1 - bump again for double-long bug on ppc(64) cvs-1.11.21-3.2 --------------- * Fri Feb 10 2006 Jesse Keating - 1.11.21-3.2 - bump again for double-long bug on ppc(64) cyrus-sasl-2.1.21-9.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 2.1.21-9.2 - bump again for double-long bug on ppc(64) dasher-3.99.4-1 --------------- * Sun Feb 12 2006 Matthias Clasen - 3.99.4-1 - Update to 3.99.4 * Fri Feb 10 2006 Jesse Keating - 3.99.2-2.2 - bump again for double-long bug on ppc(64) db4-4.3.29-1.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 4.3.29-1.2.1 - bump again for double-long bug on ppc(64) dbus-0.60-7.2 ------------- * Fri Feb 10 2006 Jesse Keating - 0.60-7.2 - bump again for double-long bug on ppc(64) dcraw-0.0.20051211-1.2 ---------------------- * Fri Feb 10 2006 Jesse Keating - 0.0.20051211-1.2 - bump again for double-long bug on ppc(64) ddd-3.3.11-5.2 -------------- * Fri Feb 10 2006 Jesse Keating - 3.3.11-5.2 - bump again for double-long bug on ppc(64) desktop-file-utils-0.10-6.1 --------------------------- * Fri Feb 10 2006 Jesse Keating - 0.10-6.1 - bump again for double-long bug on ppc(64) * Fri Feb 10 2006 Ray Strode - 0.10-6 - call update-desktop-database in %preun (bug 180898) - don't fail if update-desktop-database fails - don't use %makeinstall * Fri Feb 10 2006 Ray Strode - 0.10-5 - call update-desktop-database in %post (bug 180898) desktop-printing-0.19-5.2 ------------------------- * Fri Feb 10 2006 Jesse Keating - 0.19-5.2 - bump again for double-long bug on ppc(64) device-mapper-1.02.02-3.2 ------------------------- * Fri Feb 10 2006 Jesse Keating - 1.02.02-3.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 1.02.02-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Wed Jan 11 2006 Karel Zak - 1.02.02-3 - cleanup selinux patch - add pkg-config support device-mapper-multipath-0.4.5-12.0.1 ------------------------------------ * Fri Feb 10 2006 Jesse Keating - 0.4.5-12.0.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Benjamin Marzinski -0.4.5-12.0 - Updated to latest upstream source (t0_4_5_post56) dhcdbd-1.12-1.FC5.2 ------------------- * Fri Feb 10 2006 Jesse Keating - 1.12-1.FC5.2 - bump again for double-long bug on ppc(64) dhcp-11:3.0.3-21.1.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 11:3.0.3-21.1.1 - bump again for double-long bug on ppc(64) dhcpv6-0.10-16.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 0.10-16.1 - bump again for double-long bug on ppc(64) dialog-1.0.20051107-1.2.1 ------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.20051107-1.2.1 - bump again for double-long bug on ppc(64) dictd-1.9.15-5.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.9.15-5.2 - bump again for double-long bug on ppc(64) diffstat-1.41-1.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 1.41-1.2.1 - bump again for double-long bug on ppc(64) diffutils-2.8.1-15.2.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 2.8.1-15.2.1 - bump again for double-long bug on ppc(64) distcache-1.4.5-12.2.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 1.4.5-12.2.1 - bump again for double-long bug on ppc(64) dmraid-1.0.0.rc9-FC5_5.2 ------------------------ * Fri Feb 10 2006 Jesse Keating - 1.0.0.rc9-FC5_5.2 - bump again for double-long bug on ppc(64) dos2unix-3.1-24.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 3.1-24.2.1 - bump again for double-long bug on ppc(64) dosfstools-2.11-4.2 ------------------- * Fri Feb 10 2006 Jesse Keating - 2.11-4.2 - bump again for double-long bug on ppc(64) dovecot-1.0-0.beta2.4.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 1.0-0.beta2.4.1 - bump again for double-long bug on ppc(64) doxygen-1:1.4.6-1.2 ------------------- * Fri Feb 10 2006 Jesse Keating - 1:1.4.6-1.2 - bump again for double-long bug on ppc(64) dtach-0.7-1.2.1 --------------- * Fri Feb 10 2006 Jesse Keating - 0.7-1.2.1 - bump again for double-long bug on ppc(64) dump-0.4b41-1.2 --------------- * Fri Feb 10 2006 Jesse Keating - 0.4b41-1.2 - bump again for double-long bug on ppc(64) dvd+rw-tools-5.21.4.10.8-6.2.1 ------------------------------ * Fri Feb 10 2006 Jesse Keating - 5.21.4.10.8-6.2.1 - bump again for double-long bug on ppc(64) dvgrab-2.0-1.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 2.0-1.2.1 - bump again for double-long bug on ppc(64) e2fsprogs-1.38-6.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 1.38-6.2 - bump again for double-long bug on ppc(64) eclipse-1:3.1.2-1jpp_7fc ------------------------ * Fri Feb 10 2006 Jesse Keating - 1:3.1.2-1jpp_7fc - bump again for double-long bug on ppc(64) * Fri Feb 10 2006 Ben Konrath 3.1.2-1jpp_6fc - Update the rebuild-sdk-features script to use the 3.1 updatesite (rh#180387, rh#180768). - Make platform/feature.xml reference the tomcat5 plugin. eclipse-bugzilla-1:0.2.0_fc-2.1 ------------------------------- * Fri Feb 10 2006 Igor Foox 0.2.0-2.1 - Release bump to build. * Fri Feb 10 2006 Igor Foox 0.2.0-2 - Release bump to build. * Fri Feb 10 2006 Igor Foox 0.2.0-1.1 - Release bump to build. eclipse-cdt-1:3.0.1-1jpp_8fc ---------------------------- * Fri Feb 10 2006 Jesse Keating - 1:3.0.1-1jpp_8fc - bump again for double-long bug on ppc(64) * Fri Feb 10 2006 Andrew Overholt 3.0.1-1jpp_7fc - Use Epoch in Requires (rh#180915). - Require >= 3.1.2 but < 3.1.3 to ensure we get 3.1.2. eclipse-changelog-1:2.0.1_fc-25 ------------------------------- * Fri Feb 10 2006 Andrew Overholt 2.0.1_fc-25 - Use Epoch in Requires (rh#180915). - Require >= 3.1.2 but < 3.1.3 to ensure we get 3.1.2. ed-0.2-38.2.1 ------------- * Fri Feb 10 2006 Jesse Keating - 0.2-38.2.1 - bump again for double-long bug on ppc(64) eel2-2.13.90-1.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 2.13.90-1.2 - bump again for double-long bug on ppc(64) efax-0.9-27.2 ------------- * Fri Feb 10 2006 Jesse Keating - 0.9-27.2 - bump again for double-long bug on ppc(64) eject-2.1.2-1.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 2.1.2-1.2.1 - bump again for double-long bug on ppc(64) ekiga-1.99.0-3.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.99.0-3.2 - bump again for double-long bug on ppc(64) elfutils-0.119-1.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 0.119-1.2.1 - bump again for double-long bug on ppc(64) elinks-0.11.0-2.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 0.11.0-2.2 - bump again for double-long bug on ppc(64) emacs-21.4-12.2 --------------- * Fri Feb 10 2006 Jesse Keating - 21.4-12.2 - bump again for double-long bug on ppc(64) enscript-1.6.4-1.1.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 1.6.4-1.1.2 - bump again for double-long bug on ppc(64) eog-2.13.90-1.2 --------------- * Fri Feb 10 2006 Jesse Keating - 2.13.90-1.2 - bump again for double-long bug on ppc(64) epic-4:2.2-2.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 4:2.2-2.2.1 - bump again for double-long bug on ppc(64) epiphany-1.9.6-3 ---------------- * Sat Feb 11 2006 Matthias Clasen - 1.9.6-3 - turn on zeroconf and NetworkManager support eruby-1.0.5-5.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 1.0.5-5.2.1 - bump again for double-long bug on ppc(64) esound-1:0.2.36-2.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 1:0.2.36-2.2.1 - bump again for double-long bug on ppc(64) ethereal-0.10.14-3.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 0.10.14-3.2 - bump again for double-long bug on ppc(64) ethtool-3-1.2.1 --------------- * Fri Feb 10 2006 Jesse Keating - 3-1.2.1 - bump again for double-long bug on ppc(64) evince-0.5.0-3.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 0.5.0-3.2 - bump again for double-long bug on ppc(64) evolution-2.5.90-2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 2.5.90-2.1 - bump again for double-long bug on ppc(64) * Thu Feb 09 2006 Christopher Aillon - 2.5.90-2 - Disable the inline audio plugin for now since it uses gstreamer08 * Tue Feb 07 2006 Jesse Keating - 2.5.90-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes evolution-connector-2.5.9.0-2.2 ------------------------------- * Fri Feb 10 2006 Jesse Keating - 2.5.9.0-2.2 - bump again for double-long bug on ppc(64) evolution-data-server-1.5.90-2.2 -------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.5.90-2.2 - bump again for double-long bug on ppc(64) evolution-sharp-0.10.2-8 ------------------------ * Sun Feb 12 2006 Christopher Aillon 0.10.2-8 - Rebuild * Tue Feb 07 2006 Jesse Keating 0.10.2-7.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Tue Jan 31 2006 Christopher Aillon 0.10.2-7 - Update evolution-sharp-evo26.patch look for a SO_NUM of 7 for edataserver - BuildRequire evolution-devel evolution-webcal-2.4.1-3.2 -------------------------- * Fri Feb 10 2006 Jesse Keating - 2.4.1-3.2 - bump again for double-long bug on ppc(64) expat-1.95.8-8.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.95.8-8.2 - bump again for double-long bug on ppc(64) expect-5.43.0-3.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 5.43.0-3.1 - bump again for double-long bug on ppc(64) fbset-2.1-20.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 2.1-20.2.1 - bump again for double-long bug on ppc(64) fence-1.32.1-1 -------------- * Fri May 06 2005 Chris Feist - Cleaned up spec file (bz #157031). * Thu May 05 2005 Chris Feist - Added patch to disable starting up the init scripts. * Mon Dec 20 2004 Chris Feist - Rebuild for with new sources. fence-1.32.10-0.FC5.1.2 ----------------------- * Fri Feb 10 2006 Jesse Keating - 1.32.10-0.FC5.1.2 - bump again for double-long bug on ppc(64) festival-1.95-5.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 1.95-5.2 - bump again for double-long bug on ppc(64) fetchmail-6.3.2.1-1.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 6.3.2.1-1.2 - bump again for double-long bug on ppc(64) file-4.16-6.2 ------------- * Fri Feb 10 2006 Jesse Keating - 4.16-6.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 4.16-6.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Sat Feb 04 2006 Radek Vok??l 4.16-6 - xen patch, recognizes Xen saved domain file-roller-2.13.90-2 --------------------- * Sun Feb 12 2006 Christopher Aillon 2.13.90-2 - Rebuild * Tue Feb 07 2006 Jesse Keating 2.13.90-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Tue Jan 31 2006 Matthias Clasen 2.13.90-1 - Update to 2.13.90 filesystem-2.3.7-1.2.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 2.3.7-1.2.1 - bump again for double-long bug on ppc(64) findutils-1:4.2.27-3.2 ---------------------- * Fri Feb 10 2006 Jesse Keating - 1:4.2.27-3.2 - bump again for double-long bug on ppc(64) finger-0.17-32.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 0.17-32.2 - bump again for double-long bug on ppc(64) firefox-1.5.0.1-3 ----------------- * Fri Feb 10 2006 Christopher Aillon - 1.5.0.1-3 - Improve the langpack install stuff - Fix up dumpstack.patch to match the finalized change flac-1.1.2-25.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 1.1.2-25.2.1 - bump again for double-long bug on ppc(64) flex-2.5.4a-37.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 2.5.4a-37.2 - bump again for double-long bug on ppc(64) fontconfig-2.3.93.cvs20060211-1 ------------------------------- * Sat Feb 11 2006 Matthias Clasen - 2.3.93.cvs20060211-1 - Newer cvs snapshot * Fri Feb 10 2006 Jesse Keating - 2.3.93.cvs20060208-1.1 - bump again for double-long bug on ppc(64) fonts-arabic-1.5-5 ------------------ * Fri Feb 10 2006 Caolan McNamara - 1.5-5 - update url * Fri Dec 09 2005 Jesse Keating - rebuilt * Fri Oct 28 2005 Caolan McNamara - 1.5-4 - check for existance of fc-cache foomatic-3.0.2-33.2 ------------------- * Fri Feb 10 2006 Jesse Keating - 3.0.2-33.2 - bump again for double-long bug on ppc(64) freeglut-2.4.0-3.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 2.4.0-3.2 - bump again for double-long bug on ppc(64) freeradius-1.0.5-1.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.5-1.2 - bump again for double-long bug on ppc(64) freetype-2.1.10-5.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 2.1.10-5.2.1 - bump again for double-long bug on ppc(64) fribidi-0.10.4-8.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 0.10.4-8.2.1 - bump again for double-long bug on ppc(64) frysk-0.0.1.2006.02.12-0.FC5.0 ------------------------------ * Sun Feb 12 2006 Andrew Cagney 0.0.1.2006.02.12-0.FC5.0 - Import frysk 0.0.1.2006.02.12. ftp-0.17-32.1.2 --------------- * Fri Feb 10 2006 Jesse Keating - 0.17-32.1.2 - bump again for double-long bug on ppc(64) g-wrap-1.3.4-9.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 1.3.4-9.2.1 - bump again for double-long bug on ppc(64) gail-1.8.8-3.1 -------------- * Fri Feb 10 2006 Jesse Keating - 1.8.8-3.1 - bump again for double-long bug on ppc(64) gaim-1:1.5.0-15.fc5.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 1:1.5.0-15.fc5.1 - bump again for double-long bug on ppc(64) gal-1:0.24-6.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 1:0.24-6.2.1 - bump again for double-long bug on ppc(64) gamin-0.1.7-1.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 0.1.7-1.2.1 - bump again for double-long bug on ppc(64) gawk-3.1.5-6.1 -------------- * Fri Feb 10 2006 Jesse Keating - 3.1.5-6.1 - bump again for double-long bug on ppc(64) * Fri Feb 10 2006 Karel Zak 3.1.5-6 - fix wide characters concatenation gcc-4.1.0-0.24 -------------- * Fri Feb 10 2006 Jakub Jelinek 4.1.0-0.24 - update from gcc-4_1-branch (-r110632:110831) - PRs tree-opt/26180, c++/26070, c++/26071, fortran/25577, java/26192, libfortran/23815, libstdc++/26127, target/23359, target/26109, tree-opt/25251 - remove gcc-ppc32, gcc-c++-ppc32, gcc-sparc32 and gcc-c++-sparc32 subpackages, they do more harm than good. Particularly this time gcc*ppc32 and gcc*sparc32 defaulted to DFmode long double rather than TFmode long double gconf-editor-2.13.90-1.2 ------------------------ * Fri Feb 10 2006 Jesse Keating - 2.13.90-1.2 - bump again for double-long bug on ppc(64) gd-2.0.33-6.2 ------------- * Fri Feb 10 2006 Jesse Keating - 2.0.33-6.2 - bump again for double-long bug on ppc(64) gdb-6.3.0.0-1.98.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 6.3.0.0-1.98.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 6.3.0.0-1.98.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Mon Jan 16 2006 Alexandre Oliva 6.3.0.0-1.98 - Bump up release number. gdbm-1.8.0-26.2 --------------- * Fri Feb 10 2006 Jesse Keating - 1.8.0-26.2 - bump again for double-long bug on ppc(64) gdk-pixbuf-1:0.22.0-21.2.1 -------------------------- * Fri Feb 10 2006 Jesse Keating - 1:0.22.0-21.2.1 - bump again for double-long bug on ppc(64) gdm-1:2.13.0.7.0.2006.02.12-1 ----------------------------- * Sun Feb 12 2006 Ray Strode - 1:2.13.0.7.0.2006.02.12-1 - update to cvs snapshot - move gdm to /etc instead of /etc/X11 - move custom gdm.conf to sysconfdir instead of symlinking from datadir (bug 180364) * Fri Feb 10 2006 Jesse Keating - 1:2.13.0.7-2.1 - bump again for double-long bug on ppc(64) gedit-1:2.13.90-3.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 1:2.13.90-3.1 - bump again for double-long bug on ppc(64) genromfs-0.5.1-3.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 0.5.1-3.2.1 - bump again for double-long bug on ppc(64) geronimo-specs-0:1.0-0.M2.2jpp_7fc ---------------------------------- * Fri Feb 10 2006 Jesse Keating - 0:1.0-0.M2.2jpp_7fc - bump again for double-long bug on ppc(64) gettext-0.14.5-2.2.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 0.14.5-2.2.2 - bump again for double-long bug on ppc(64) gftp-1:2.0.18-3.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 1:2.0.18-3.2.1 - bump again for double-long bug on ppc(64) ghostscript-8.15.1-5.2 ---------------------- * Fri Feb 10 2006 Jesse Keating - 8.15.1-5.2 - bump again for double-long bug on ppc(64) giflib-4.1.3-6.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 4.1.3-6.2.1 - bump again for double-long bug on ppc(64) gimp-2:2.2.10-2.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 2:2.2.10-2.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 2:2.2.10-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Tue Jan 10 2006 Nils Philippsen - rebuild with lcms gimp-print-4.2.7-15.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 4.2.7-15.2 - bump again for double-long bug on ppc(64) gjdoc-0.7.7-3.1 --------------- * Fri Feb 10 2006 Jesse Keating - 0.7.7-3.1 - bump again for double-long bug on ppc(64) gkrellm-2.2.7-5.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 2.2.7-5.2.1 - bump again for double-long bug on ppc(64) glade2-2.12.1-2 --------------- * Sat Feb 11 2006 Matthias Clasen - 2.12.1-2 - Remove requires for gail-devel that has been unnecessary since 2002 * Fri Feb 10 2006 Jesse Keating - 2.12.1-1.2.1 - bump again for double-long bug on ppc(64) glib-1:1.2.10-18.2.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 1:1.2.10-18.2.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 1:1.2.10-18.2.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Tue Jan 03 2006 Jesse Keating 1:1.2.10-18.2 - rebuilt again glib-java-0.2.3-1.2 ------------------- * Fri Feb 10 2006 Jesse Keating - 0.2.3-1.2 - bump again for double-long bug on ppc(64) glib2-2.9.6-1 ------------- * Sun Feb 12 2006 Matthias Clasen - 2.9.6-1 - Update to 2.9.6 * Fri Feb 10 2006 Jesse Keating - 2.9.5-1.2 - bump again for double-long bug on ppc(64) glibc-kernheaders-3.0-5.2 ------------------------- * Fri Feb 10 2006 Jesse Keating - 3.0-5.2 - bump again for double-long bug on ppc(64) gmp-4.1.4-6.2.1 --------------- * Fri Feb 10 2006 Jesse Keating - 4.1.4-6.2.1 - bump again for double-long bug on ppc(64) gnome-applet-vm-0.0.6-1 ----------------------- * Fri Feb 10 2006 Karel Zak 0.0.6-1 - new upstream version * Thu Feb 09 2006 Daniel Veillard - 0.0.5-1.2 - rebuilt to update depends on libvirt following library rename gnome-applets-1:2.13.4-1 ------------------------ * Sun Feb 12 2006 Matthias Clasen - 2.13.4-1 - Update to 2.13.4 * Fri Feb 10 2006 Jesse Keating - 1:2.13.3-4.2 - bump again for double-long bug on ppc(64) gnome-bluetooth-0.6.0-2.2.1 --------------------------- * Fri Feb 10 2006 Jesse Keating - 0.6.0-2.2.1 - bump again for double-long bug on ppc(64) gnome-desktop-2.13.90-1.2 ------------------------- * Fri Feb 10 2006 Jesse Keating - 2.13.90-1.2 - bump again for double-long bug on ppc(64) gnome-doc-utils-0.5.5-1 ----------------------- * Sun Feb 12 2006 Matthias Clasen - 0.5.5-1 - Update to 0.5.5 gnome-games-1:2.13.6-3.2 ------------------------ * Fri Feb 10 2006 Jesse Keating - 1:2.13.6-3.2 - bump again for double-long bug on ppc(64) gnome-icon-theme-2.14.0-1 ------------------------- * Sun Feb 12 2006 Ray Strode 2.14.0-1 - Update to 2.14.0 gnome-kerberos-0.3.3-2.2.1 -------------------------- * Fri Feb 10 2006 Jesse Keating - 0.3.3-2.2.1 - bump again for double-long bug on ppc(64) gnome-keyring-0.4.6-1.2.1 ------------------------- * Fri Feb 10 2006 Jesse Keating - 0.4.6-1.2.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 0.4.6-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-keyring-manager-2.12.0-2.2.1 ---------------------------------- * Fri Feb 10 2006 Jesse Keating - 2.12.0-2.2.1 - bump again for double-long bug on ppc(64) gnome-libs-1:1.4.1.2.90-48.2 ---------------------------- * Fri Feb 10 2006 Jesse Keating - 1:1.4.1.2.90-48.2 - bump again for double-long bug on ppc(64) gnome-mag-0.12.3-2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 0.12.3-2.1 - bump again for double-long bug on ppc(64) gnome-media-2.13.91-2.2 ----------------------- * Fri Feb 10 2006 Jesse Keating - 2.13.91-2.2 - bump again for double-long bug on ppc(64) gnome-menus-2.13.5-5.2 ---------------------- * Fri Feb 10 2006 Jesse Keating - 2.13.5-5.2 - bump again for double-long bug on ppc(64) gnome-mime-data-2.4.2-1.2.1 --------------------------- * Fri Feb 10 2006 Jesse Keating - 2.4.2-1.2.1 - bump again for double-long bug on ppc(64) gnome-netstatus-2.12.0-3.2.1 ---------------------------- * Fri Feb 10 2006 Jesse Keating - 2.12.0-3.2.1 - bump again for double-long bug on ppc(64) gnome-nettool-2.13.90-1.2 ------------------------- * Fri Feb 10 2006 Jesse Keating - 2.13.90-1.2 - bump again for double-long bug on ppc(64) gnome-panel-2.13.90-1.2 ----------------------- * Fri Feb 10 2006 Jesse Keating - 2.13.90-1.2 - bump again for double-long bug on ppc(64) gnome-pilot-2.0.13-7.fc5.2.1 ---------------------------- * Fri Feb 10 2006 Jesse Keating - 2.0.13-7.fc5.2.1 - bump again for double-long bug on ppc(64) gnome-pilot-conduits-2.0.13-3.FC5.2 ----------------------------------- * Fri Feb 10 2006 Jesse Keating - 2.0.13-3.FC5.2 - bump again for double-long bug on ppc(64) gnome-power-manager-2.13.5.0.20060207-1.1 ----------------------------------------- * Fri Feb 10 2006 Jesse Keating - 2.13.5.0.20060207-1.1 - bump again for double-long bug on ppc(64) gnome-print-1:0.37-12.2.1 ------------------------- * Fri Feb 10 2006 Jesse Keating - 1:0.37-12.2.1 - bump again for double-long bug on ppc(64) gnome-python2-2.12.3-1.2 ------------------------ * Fri Feb 10 2006 Jesse Keating - 2.12.3-1.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 2.12.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Mon Feb 06 2006 John (J5) Palmieri - 2.12.3-1 - Update to 2.12.3 gnome-python2-desktop-2.13.3-1.1 -------------------------------- gnome-python2-extras-2.13.3-3.2 ------------------------------- * Fri Feb 10 2006 Jesse Keating - 2.13.3-3.2 - bump again for double-long bug on ppc(64) gnome-screensaver-2.13.90-3.1 ----------------------------- * Fri Feb 10 2006 Jesse Keating - 2.13.90-3.1 - bump again for double-long bug on ppc(64) * Fri Feb 10 2006 Ray Strode - 2.13.90-3 - take some more measures to cut cpu usage down gnome-session-2.13.90-1.2 ------------------------- * Fri Feb 10 2006 Jesse Keating - 2.13.90-1.2 - bump again for double-long bug on ppc(64) gnome-speech-0.3.9-1.2.1 ------------------------ * Fri Feb 10 2006 Jesse Keating - 0.3.9-1.2.1 - bump again for double-long bug on ppc(64) gnome-spell-1.0.5-13.2 ---------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.5-13.2 - bump again for double-long bug on ppc(64) gnome-system-monitor-2.13.90-1.2 -------------------------------- * Fri Feb 10 2006 Jesse Keating - 2.13.90-1.2 - bump again for double-long bug on ppc(64) gnome-terminal-2.13.91-1 ------------------------ * Sun Feb 12 2006 Matthias Clasen - 2.13.91-1 - Update to 2.13.91 * Fri Feb 10 2006 Jesse Keating - 2.13.90-2.1 - bump again for double-long bug on ppc(64) gnome-user-share-0.9-2.2 ------------------------ * Fri Feb 10 2006 Jesse Keating - 0.9-2.2 - bump again for double-long bug on ppc(64) gnome-utils-1:2.13.92-1 ----------------------- * Sun Feb 12 2006 Matthias Clasen 2.13.92-1 - Update to gnome-utils 2.13.92 * Fri Feb 10 2006 Jesse Keating - 1:2.13.91-2.2 - bump again for double-long bug on ppc(64) gnome-vfs2-2.13.4-7.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 2.13.4-7.2 - bump again for double-long bug on ppc(64) gnome-volume-manager-1.5.11-1.2 ------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.5.11-1.2 - bump again for double-long bug on ppc(64) gnopernicus-1.0.1-1.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1-1.2 - bump again for double-long bug on ppc(64) gnucash-1.8.12-2.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 1.8.12-2.2 - bump again for double-long bug on ppc(64) gnupg-1.4.2-3.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 1.4.2-3.2.1 - bump again for double-long bug on ppc(64) gnuplot-4.0.0-10.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 4.0.0-10.2.1 - bump again for double-long bug on ppc(64) gnutls-1.2.9-3.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.2.9-3.2 - bump again for double-long bug on ppc(64) gob2-2.0.12-1.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 2.0.12-1.2.1 - bump again for double-long bug on ppc(64) gok-1.0.5-6.2.1 --------------- * Fri Feb 10 2006 Jesse Keating - 1.0.5-6.2.1 - bump again for double-long bug on ppc(64) gperf-3.0.1-7.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 3.0.1-7.2.1 - bump again for double-long bug on ppc(64) gphoto2-2.1.99-5.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 2.1.99-5.2 - bump again for double-long bug on ppc(64) grep-2.5.1-52.2 --------------- * Fri Feb 10 2006 Jesse Keating - 2.5.1-52.2 - bump again for double-long bug on ppc(64) groff-1.18.1.1-9.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 1.18.1.1-9.2 - bump again for double-long bug on ppc(64) gsf-sharp-0.6-7 --------------- * Sun Feb 12 2006 Christopher Aillon 0.6-7 - Rebuild gsl-1.7-1.2.1 ------------- * Fri Feb 10 2006 Jesse Keating - 1.7-1.2.1 - bump again for double-long bug on ppc(64) gstreamer-0.10.3-1 ------------------ * Fri Feb 10 2006 Christopher Aillon - 0.10.3-2 - Update to 0.10.3 * Tue Feb 07 2006 Jesse Keating - 0.10.2-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Wed Jan 18 2006 John (J5) Palmieri - 0.10.2-1 - Upgrade to 0.10.2 gstreamer-plugins-base-0.10.3-1 ------------------------------- * Fri Feb 10 2006 Christopher Aillon - 0.10.3-1 - Update to 0.10.3 gstreamer-plugins-good-0.10.2-1 ------------------------------- * Fri Feb 10 2006 Christopher Aillon - 0.10.2-1 - Update to 0.10.2 gthumb-2.7.2-2.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 2.7.2-2.2 - bump again for double-long bug on ppc(64) gtk+-1:1.2.10-49.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 1:1.2.10-49.2.1 - bump again for double-long bug on ppc(64) gtk-engines-1:0.12-7.2.1 ------------------------ * Fri Feb 10 2006 Jesse Keating - 1:0.12-7.2.1 - bump again for double-long bug on ppc(64) gtk-sharp2-2.8.1-1 ------------------ * Fri Feb 10 2006 Christopher Aillon - 2.8.1-1 - Update to 2.8.1 gtk2-2.8.12-7.1 --------------- * Sat Feb 11 2006 Matthias Clasen - 2.8.12-1 - Update to 2.8.12 * Fri Feb 10 2006 Jesse Keating - 2.8.11-7.1 - bump again for double-long bug on ppc(64) * Thu Feb 09 2006 Matthias Clasen 2.8.11-7 - Fix a double free in the file chooser gtk2-engines-2.7.4-1.2 ---------------------- * Fri Feb 10 2006 Jesse Keating - 2.7.4-1.2 - bump again for double-long bug on ppc(64) gtkhtml-1.1.9-11.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 1.1.9-11.2.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 1.1.9-11.2 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 09 2005 Jesse Keating - rebuilt gtkhtml2-2.6.3-1.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 2.6.3-1.2.1 - bump again for double-long bug on ppc(64) gtkhtml3-3.9.90-3.2 ------------------- * Fri Feb 10 2006 Jesse Keating - 3.9.90-3.2 - bump again for double-long bug on ppc(64) gtksourceview-1.5.7-2.2 ----------------------- * Fri Feb 10 2006 Jesse Keating - 1.5.7-2.2 - bump again for double-long bug on ppc(64) gtkspell-2.0.11-1.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 2.0.11-1.2.1 - bump again for double-long bug on ppc(64) guile-5:1.6.7-5.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 5:1.6.7-5.2 - bump again for double-long bug on ppc(64) gulm-1.0.0-2 ------------ * Sun May 08 2005 Florian La Roche - mv /etc/init.d -> /etc/rc.d/init.d - fix requires: * Fri May 06 2005 Chris Feist - fixed various problems with .spec file * Thu May 05 2005 Bill Nottingham - fix chkconfig line gulm-1.0.5-0.FC5.1.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.5-0.FC5.1.2 - bump again for double-long bug on ppc(64) gwenhywfar-1.99.2-1.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 1.99.2-1.2 - bump again for double-long bug on ppc(64) gzip-1.3.5-6.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.3.5-6.2.1 - bump again for double-long bug on ppc(64) h2ps-2.06-14.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 2.06-14.2.1 - bump again for double-long bug on ppc(64) hal-cups-utils-0.5.5-1.2 ------------------------ * Fri Feb 10 2006 Jesse Keating - 0.5.5-1.2 - bump again for double-long bug on ppc(64) hardlink-1:1.0-1.21.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 1:1.0-1.20.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 1:1.0-1.19.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 09 2005 Jesse Keating - rebuilt hdparm-6.3-2.2 -------------- * Fri Feb 10 2006 Jesse Keating - 6.3-2.2 - bump again for double-long bug on ppc(64) hesiod-3.0.2-31.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 3.0.2-31.2.1 - bump again for double-long bug on ppc(64) hexedit-1.2.12-3.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 1.2.12-3.2 - bump again for double-long bug on ppc(64) hfsutils-3.2.6-7.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 3.2.6-7.2.1 - bump again for double-long bug on ppc(64) hplip-0.9.8-3.1 --------------- * Fri Feb 10 2006 Jesse Keating - (none):0.9.8-3.1 - bump again for double-long bug on ppc(64) hsqldb-0:1.80.1-1jpp_7fc ------------------------ * Fri Feb 10 2006 Jesse Keating - 0:1.80.1-1jpp_7fc - bump again for double-long bug on ppc(64) htdig-3:3.2.0b6-6.4.2.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 3:3.2.0b6-6.4.2.1 - bump again for double-long bug on ppc(64) httpd-2.2.0-5.1.2 ----------------- * Fri Feb 10 2006 Jesse Keating - (none):2.2.0-5.1.2 - bump again for double-long bug on ppc(64) icon-slicer-0.3-7.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 0.3-7.2.1 - bump again for double-long bug on ppc(64) icu-3.4-6.2 ----------- * Fri Feb 10 2006 Jesse Keating - 3.4-6.2 - bump again for double-long bug on ppc(64) iddev-2.0.0-4.FC5.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 2.0.0-4.FC5.2.1 - bump again for double-long bug on ppc(64) imake-1.0.1-1.2 --------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1-1.2 - bump again for double-long bug on ppc(64) imlib-1:1.9.13-26.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 1:1.9.13-26.2.1 - bump again for double-long bug on ppc(64) indent-2.2.9-12.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 2.2.9-12.2 - bump again for double-long bug on ppc(64) initscripts-8.26-1.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 8.26-1.1 - bump again for double-long bug on ppc(64) inn-2.4.2-4.2.1 --------------- * Fri Feb 10 2006 Jesse Keating - 2.4.2-4.2.1 - bump again for double-long bug on ppc(64) intltool-0.34.2-1.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 0.34.2-1.1 - bump again for double-long bug on ppc(64) iproute-2.6.15-1.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 2.6.15-1.2 - bump again for double-long bug on ppc(64) iprutils-2.1.1-1.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 2.1.1-1.2 - bump again for double-long bug on ppc(64) ipsec-tools-0.6.4-1.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 0.6.4-1.1 - bump again for double-long bug on ppc(64) iptables-1.3.5-1.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 1.3.5-1.2 - bump again for double-long bug on ppc(64) iptraf-3.0.0-1.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 3.0.0-1.2 - bump again for double-long bug on ppc(64) iptstate-1.4-1.1.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 1.4-1.1.2.1 - bump again for double-long bug on ppc(64) iputils-20020927-34.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 20020927-34.2 - bump again for double-long bug on ppc(64) ipv6calc-0.50-1.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 0.50-1.2.1 - bump again for double-long bug on ppc(64) ipvsadm-1.24-7.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 1.24-7.2.1 - bump again for double-long bug on ppc(64) irda-utils-0.9.16-7.2.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 0.9.16-7.2.1 - bump again for double-long bug on ppc(64) irqbalance-1:1.12-1.24 ---------------------- * Sun Feb 12 2006 Dave Jones - Build for ppc[64] too. iscsi-initiator-utils-5.0.5.476-0.1 ----------------------------------- isdn4k-utils-3.2-38.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 3.2-38.2 - bump again for double-long bug on ppc(64) isicom-3.05-18.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 3.05-18.2.1 - bump again for double-long bug on ppc(64) jakarta-commons-beanutils-0:1.7.0-2jpp_5fc ------------------------------------------ * Fri Feb 10 2006 Jesse Keating - sh: line 1: build-classpath: command not found - bump again for double-long bug on ppc(64) jakarta-commons-collections-0:3.1-2jpp_4fc ------------------------------------------ * Fri Feb 10 2006 Jesse Keating - 0:3.1-2jpp_4fc - bump again for double-long bug on ppc(64) jakarta-commons-digester-0:1.6-2jpp_8fc --------------------------------------- * Fri Feb 10 2006 Jesse Keating - sh: line 1: build-classpath: command not found - bump again for double-long bug on ppc(64) jakarta-commons-el-0:1.0-4jpp_5fc --------------------------------- * Fri Feb 10 2006 Jesse Keating - 0:1.0-4jpp_5fc - bump again for double-long bug on ppc(64) jakarta-commons-logging-0:1.0.4-2jpp_9fc ---------------------------------------- * Fri Feb 10 2006 Jesse Keating - 0:1.0.4-2jpp_9fc - bump again for double-long bug on ppc(64) jakarta-commons-modeler-0:1.1-4jpp_5fc -------------------------------------- * Fri Feb 10 2006 Jesse Keating - 0:1.1-4jpp_5fc - bump again for double-long bug on ppc(64) java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_80rh ------------------------------------------ * Fri Feb 10 2006 Jesse Keating - 0:1.4.2.0-40jpp_80rh - bump again for double-long bug on ppc(64) * Fri Feb 10 2006 Thomas Fitzsimmons - 0:1.4.2.0-40jpp_79rh - Install compatibility amd64 symlink. java_cup-1:0.10-0.k.1jpp_8fc ---------------------------- * Fri Feb 10 2006 Jesse Keating - 1:0.10-0.k.1jpp_8fc - bump again for double-long bug on ppc(64) javacc-0:3.2-1jpp_6fc --------------------- * Fri Feb 10 2006 Jesse Keating - 0:3.2-1jpp_6fc - bump again for double-long bug on ppc(64) jfsutils-1.1.10-3.2 ------------------- * Fri Feb 10 2006 Jesse Keating - 1.1.10-3.2 - bump again for double-long bug on ppc(64) joe-3.3-1.2.1 ------------- * Fri Feb 10 2006 Jesse Keating - 3.3-1.2.1 - bump again for double-long bug on ppc(64) joystick-1.2.15-20.2.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 1.2.15-20.2.1 - bump again for double-long bug on ppc(64) jpilot-0.99.8-2.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 0.99.8-2.2.1 - bump again for double-long bug on ppc(64) jsch-0:0.1.18-1jpp_6fc ---------------------- * Fri Feb 10 2006 Jesse Keating - 0:0.1.18-1jpp_6fc - bump again for double-long bug on ppc(64) jwhois-3.2.3-3.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 3.2.3-3.2.1 - bump again for double-long bug on ppc(64) k3b-0:0.12.10-2.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 0:0.12.10-2.2 - bump again for double-long bug on ppc(64) kasumi-1.0-1.fc5.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 1.0-1.fc5.2 - bump again for double-long bug on ppc(64) kbd-1.12-13.2 ------------- * Fri Feb 10 2006 Jesse Keating - 1.12-13.2 - bump again for double-long bug on ppc(64) kcc-2.3-24.2.1 -------------- * Fri Feb 10 2006 Jesse Keating - 2.3-24.2.1 - bump again for double-long bug on ppc(64) kdbg-1:2.0.2-1.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 1:2.0.2-1.2 - bump again for double-long bug on ppc(64) kdeaccessibility-1:3.5.1-1.2 ---------------------------- * Fri Feb 10 2006 Jesse Keating - 1:3.5.1-1.2 - bump again for double-long bug on ppc(64) kdeaddons-3.5.1-1.2 ------------------- * Fri Feb 10 2006 Jesse Keating - 3.5.1-1.2 - bump again for double-long bug on ppc(64) kdeadmin-7:3.5.1-1.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 7:3.5.1-1.2 - bump again for double-long bug on ppc(64) kdeartwork-3.5.1-1.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 3.5.1-1.2 - bump again for double-long bug on ppc(64) kdebase-6:3.5.1-2.2 ------------------- * Fri Feb 10 2006 Jesse Keating - 6:3.5.1-2.2 - bump again for double-long bug on ppc(64) kdebindings-3.5.1-1.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 3.5.1-1.2 - bump again for double-long bug on ppc(64) kdeedu-3.5.1-1.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 3.5.1-1.2 - bump again for double-long bug on ppc(64) kdegames-6:3.5.1-1.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 6:3.5.1-1.2 - bump again for double-long bug on ppc(64) kdegraphics-7:3.5.1-2.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 7:3.5.1-2.1 - bump again for double-long bug on ppc(64) kdelibs-6:3.5.1-2.2 ------------------- * Fri Feb 10 2006 Jesse Keating - 6:3.5.1-2.2 - bump again for double-long bug on ppc(64) kdemultimedia-6:3.5.1-1.2 ------------------------- * Fri Feb 10 2006 Jesse Keating - 6:3.5.1-1.2 - bump again for double-long bug on ppc(64) kdenetwork-7:3.5.1-1.2 ---------------------- * Fri Feb 10 2006 Jesse Keating - 7:3.5.1-1.2 - bump again for double-long bug on ppc(64) kdepim-6:3.5.1-1.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 6:3.5.1-1.2 - bump again for double-long bug on ppc(64) kdesdk-3.5.1-1.2 ---------------- * Fri Feb 10 2006 Jesse Keating - (none):3.5.1-1.2 - bump again for double-long bug on ppc(64) kdeutils-6:3.5.1-1.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 6:3.5.1-1.2 - bump again for double-long bug on ppc(64) kdevelop-9:3.3.1-1.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 9:3.3.1-1.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 9:3.3.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes kdewebdev-6:3.5.1-1.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 6:3.5.1-1.2 - bump again for double-long bug on ppc(64) kernel-2.6.15-1.1939_FC5 ------------------------ * Sun Feb 12 2006 Dave Jones - 2.6.16rc2-git11 & -git12 - Fix warning in bcm43xx driver. - Missing license tag in p8023 - Fix oops in bluetooth - Ratelimit some networking messages - Only print migration info on SMP * Sat Feb 11 2006 Dave Jones - 2.6.16rc2-git10 * Fri Feb 10 2006 Dave Jones - 2.6.16rc2-git8 & -git9 - Begin the kernel-xen & kernel merge by merging the easy bits. - Remove x86_64 TIF_RESTORE_SIGMASK & generic sys_rt_sigsuspend (They seemed to cause big problems) krb5-1.4.3-4.1 -------------- * Fri Feb 10 2006 Jesse Keating - 1.4.3-4.1 - bump again for double-long bug on ppc(64) krbafs-1.2.2-9.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 1.2.2-9.2.1 - bump again for double-long bug on ppc(64) kudzu-1.2.25-1.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.2.25-1.1 - bump again for double-long bug on ppc(64) lam-2:7.1.1-8.FC5.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 2:7.1.1-8.FC5.2.1 - bump again for double-long bug on ppc(64) lcms-1.15-1.2 ------------- * Fri Feb 10 2006 Jesse Keating - 1.15-1.2 - bump again for double-long bug on ppc(64) less-394-2.2 ------------ * Fri Feb 10 2006 Jesse Keating - 394-2.2 - bump again for double-long bug on ppc(64) lftp-3.4.2-1.1 -------------- * Fri Feb 10 2006 Jesse Keating - 3.4.2-1.1 - bump again for double-long bug on ppc(64) lha-1.14i-19.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.14i-19.2.1 - bump again for double-long bug on ppc(64) libFS-1.0.0-2.2 --------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0-2.2 - bump again for double-long bug on ppc(64) libICE-1.0.0-2.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0-2.2 - bump again for double-long bug on ppc(64) libIDL-0.8.6-2.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 0.8.6-2.2.1 - bump again for double-long bug on ppc(64) libSM-1.0.0-2.2 --------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0-2.2 - bump again for double-long bug on ppc(64) libX11-1.0.0-2.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0-2.2 - bump again for double-long bug on ppc(64) libXScrnSaver-1.0.1-1.2 ----------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1-1.2 - bump again for double-long bug on ppc(64) libXTrap-1.0.0-2.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 1.0.0-2.2 - bump again for double-long bug on ppc(64) libXau-1.0.0-2.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0-2.2 - bump again for double-long bug on ppc(64) libXaw-1.0.1-1.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1-1.2 - bump again for double-long bug on ppc(64) libXcomposite-0.2.2.2-2.2 ------------------------- * Fri Feb 10 2006 Jesse Keating - 0.2.2.2-2.2 - bump again for double-long bug on ppc(64) libXcursor-1.1.5.2-2.2 ---------------------- * Fri Feb 10 2006 Jesse Keating - 1.1.5.2-2.2 - bump again for double-long bug on ppc(64) libXdamage-1.0.2.2-2.2 ---------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.2.2-2.2 - bump again for double-long bug on ppc(64) libXdmcp-1.0.0-2.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 1.0.0-2.2 - bump again for double-long bug on ppc(64) libXevie-1.0.0-2.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 1.0.0-2.2 - bump again for double-long bug on ppc(64) libXext-1.0.0-3.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0-3.2 - bump again for double-long bug on ppc(64) libXfixes-3.0.1.2-2.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 3.0.1.2-2.2 - bump again for double-long bug on ppc(64) libXfont-1.0.0-2.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 1.0.0-2.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 1.0.0-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Mon Jan 23 2006 Mike A. Harris 1.0.0-2 - Bumped and rebuilt libXfontcache-1.0.1-1.2 ----------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1-1.2 - bump again for double-long bug on ppc(64) libXft-2.1.8.2-3.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 2.1.8.2-3.2 - bump again for double-long bug on ppc(64) libXi-1.0.0-2.2 --------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0-2.2 - bump again for double-long bug on ppc(64) libXinerama-1.0.1-1.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1-1.2 - bump again for double-long bug on ppc(64) libXmu-1.0.0-2.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0-2.2 - bump again for double-long bug on ppc(64) libXp-1.0.0-2.2 --------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0-2.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 1.0.0-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Mon Jan 23 2006 Mike A. Harris 1.0.0-2 - Bumped and rebuilt libXpm-3.5.4.2-2.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 3.5.4.2-2.2 - bump again for double-long bug on ppc(64) libXrandr-1.1.0.2-2.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 1.1.0.2-2.2 - bump again for double-long bug on ppc(64) libXrender-0.9.0.2-3.2 ---------------------- * Fri Feb 10 2006 Jesse Keating - 0.9.0.2-3.2 - bump again for double-long bug on ppc(64) libXres-1.0.0-2.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0-2.2 - bump again for double-long bug on ppc(64) libXt-1.0.0-2.2 --------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0-2.2 - bump again for double-long bug on ppc(64) libXtst-1.0.1-1.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1-1.2 - bump again for double-long bug on ppc(64) libXv-1.0.1-1.2 --------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1-1.2 - bump again for double-long bug on ppc(64) libXvMC-1.0.1-2.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1-2.2 - bump again for double-long bug on ppc(64) libXxf86dga-1.0.0-2.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0-2.2 - bump again for double-long bug on ppc(64) libXxf86misc-1.0.0-2.2 ---------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0-2.2 - bump again for double-long bug on ppc(64) libXxf86vm-1.0.0-2.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0-2.2 - bump again for double-long bug on ppc(64) libaio-0.3.106-2.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 0.3.106-2.2 - bump again for double-long bug on ppc(64) libao-0.8.6-1.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 0.8.6-1.2.1 - bump again for double-long bug on ppc(64) libart_lgpl-2.3.17-2.2.1 ------------------------ * Fri Feb 10 2006 Jesse Keating - 2.3.17-2.2.1 - bump again for double-long bug on ppc(64) libavc1394-0.5.1-2.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 0.5.1-2.2 - bump again for double-long bug on ppc(64) libbonobo-2.13.1-8.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 2.13.1-8.2 - bump again for double-long bug on ppc(64) libbonoboui-2.13.1-4.2 ---------------------- * Fri Feb 10 2006 Jesse Keating - 2.13.1-4.2 - bump again for double-long bug on ppc(64) libc-client-2004g-2.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 2004g-2.2 - bump again for double-long bug on ppc(64) libcap-1.10-24.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.10-24.2 - bump again for double-long bug on ppc(64) libchewing-0.2.7-1.2.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 0.2.7-1.2.1 - bump again for double-long bug on ppc(64) libcroco-0.6.0-6.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 0.6.0-6.2.1 - bump again for double-long bug on ppc(64) libdaemon-0.10-3.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 0.10-3.1 - bump again for double-long bug on ppc(64) libdbi-0.8.1-1.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 0.8.1-1.2.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 0.8.1-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 09 2005 Jesse Keating - rebuilt libdbi-drivers-0.8.1a-1.2.1 --------------------------- * Fri Feb 10 2006 Jesse Keating - 0.8.1a-1.2.1 - bump again for double-long bug on ppc(64) libdmx-1.0.1-1.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1-1.2 - bump again for double-long bug on ppc(64) libdrm-2.0-2.2 -------------- * Fri Feb 10 2006 Jesse Keating - 2.0-2.2 - bump again for double-long bug on ppc(64) libevent-1.1a-3.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 1.1a-3.2 - bump again for double-long bug on ppc(64) libexif-0.6.12-3.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 0.6.12-3.2.1 - bump again for double-long bug on ppc(64) libfontenc-1.0.1-1.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1-1.2 - bump again for double-long bug on ppc(64) libgail-gnome-1.1.3-1.2 ----------------------- * Fri Feb 10 2006 Jesse Keating - 1.1.3-1.2 - bump again for double-long bug on ppc(64) libgconf-java-2.12.1-2.2 ------------------------ * Fri Feb 10 2006 Jesse Keating - 2.12.1-2.2 - bump again for double-long bug on ppc(64) libgcrypt-1.2.2-1.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 1.2.2-1.2.1 - bump again for double-long bug on ppc(64) libgdiplus-1.1.13.2-2 --------------------- * Fri Feb 10 2006 Christopher Aillon - 1.1.13.2-2 - Rebuild libghttp-1:1.0.9-11.2.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 1:1.0.9-11.2.1 - bump again for double-long bug on ppc(64) libglade-1:0.17-16.2.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 1:0.17-16.2.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 1:0.17-16.2 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 09 2005 Jesse Keating - rebuilt libglade-java-2.12.2-1.2 ------------------------ * Fri Feb 10 2006 Jesse Keating - 2.12.2-1.2 - bump again for double-long bug on ppc(64) libglade2-2.5.1-3.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 2.5.1-3.2.1 - bump again for double-long bug on ppc(64) libgnome-2.13.7-5.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 2.13.7-5.1 - bump again for double-long bug on ppc(64) * Thu Feb 09 2006 Matthias Clasen - 2.13.7-5 - Rebuild * Tue Feb 07 2006 Jesse Keating - 2.13.7-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes libgnome-java-2.12.1-3.2 ------------------------ * Fri Feb 10 2006 Jesse Keating - 2.12.1-3.2 - bump again for double-long bug on ppc(64) libgnomecanvas-2.13.0-1.2 ------------------------- * Fri Feb 10 2006 Jesse Keating - 2.13.0-1.2 - bump again for double-long bug on ppc(64) libgnomecups-0.2.2-3.2.1 ------------------------ * Fri Feb 10 2006 Jesse Keating - 0.2.2-3.2.1 - bump again for double-long bug on ppc(64) libgnomeprint22-2.12.1-4.2 -------------------------- * Fri Feb 10 2006 Jesse Keating - 2.12.1-4.2 - bump again for double-long bug on ppc(64) libgnomeprintui22-2.12.1-1.2.1 ------------------------------ * Fri Feb 10 2006 Jesse Keating - 2.12.1-1.2.1 - bump again for double-long bug on ppc(64) libgnomeui-2.13.3-1.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 2.13.3-1.2 - bump again for double-long bug on ppc(64) libgpg-error-1.1-1.2.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 1.1-1.2.1 - bump again for double-long bug on ppc(64) libgpod-0.3.0-2.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 0.3.0-2.2 - bump again for double-long bug on ppc(64) libgsf-1.13.3-2.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 1.13.3-2.2.1 - bump again for double-long bug on ppc(64) libgssapi-0.7-2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 0.7-2.1 - bump again for double-long bug on ppc(64) libgtk-java-2.8.3-1.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 2.8.3-1.2 - bump again for double-long bug on ppc(64) libgtop2-2.13.3-1.2 ------------------- * Fri Feb 10 2006 Jesse Keating - 2.13.3-1.2 - bump again for double-long bug on ppc(64) libibverbs-1.0.rc4-0.4265.1.FC5.2.1 ----------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.rc4-0.4265.1.FC5.2.1 - bump again for double-long bug on ppc(64) libidn-0.6.2-1.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 0.6.2-1.1 - bump again for double-long bug on ppc(64) libiec61883-1.0.0-10.fc5.2 -------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0-10.fc5.2 - bump again for double-long bug on ppc(64) libieee1284-0.2.9-3.2.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 0.2.9-3.2.1 - bump again for double-long bug on ppc(64) libjpeg-6b-36.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 6b-36.2.1 - bump again for double-long bug on ppc(64) liblbxutil-1.0.0-2.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.0-2.2 - bump again for double-long bug on ppc(64) libmng-1.0.9-3.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 1.0.9-3.2.1 - bump again for double-long bug on ppc(64) libmthca-1.0.rc4-0.4265.1.FC5.2.1 --------------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.rc4-0.4265.1.FC5.2.1 - bump again for double-long bug on ppc(64) libmusicbrainz-2.1.1-2.1 ------------------------ * Fri Feb 10 2006 Jesse Keating - 2.1.1-2.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Christopher Aillon - 2.1.1-2 - Stop shipping the .a file in the main package libnl-1.0-0.8.pre5 ------------------ * Sun Feb 12 2006 Christopher Aillon 1.0-0.8.pre5 - Rebuild * Tue Feb 07 2006 Jesse Keating 1.0-0.7.pre5.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Mon Jan 16 2006 Christopher Aillon 1.0-0.7.pre5 - Add patch to not chown files to root.root during make install; it happens normally. libnotify-0.3.0-4.2 ------------------- * Fri Feb 10 2006 Jesse Keating - 0.3.0-4.2 - bump again for double-long bug on ppc(64) libofx-0.8.0-2.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 0.8.0-2.2 - bump again for double-long bug on ppc(64) libogg-2:1.1.3-1.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 2:1.1.3-1.2 - bump again for double-long bug on ppc(64) liboil-0.3.6-3.fc5.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 0.3.6-3.fc5.2 - bump again for double-long bug on ppc(64) liboldX-1.0.1-1.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1-1.2 - bump again for double-long bug on ppc(64) libpng-2:1.2.8-2.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 2:1.2.8-2.2.1 - bump again for double-long bug on ppc(64) libpng10-1.0.18-3.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.18-3.2.1 - bump again for double-long bug on ppc(64) libraw1394-1.2.0-3.fc5.2 ------------------------ * Fri Feb 10 2006 Jesse Keating - 1.2.0-3.fc5.2 - bump again for double-long bug on ppc(64) librsvg2-2.13.93-1 ------------------ * Sat Feb 11 2006 Matthias Clasen 2.13.93-1 - Update to 2.13.93 * Fri Feb 10 2006 Jesse Keating - 2.13.92-1.1 - bump again for double-long bug on ppc(64) librtas-1.2.4-1.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 1.2.4-1.2.1 - bump again for double-long bug on ppc(64) libsdp-0.90-0.4265.1.FC5.2.1 ---------------------------- * Fri Feb 10 2006 Jesse Keating - 0.90-0.4265.1.FC5.2.1 - bump again for double-long bug on ppc(64) libselinux-1.29.7-1.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 1.29.7-1.2 - bump again for double-long bug on ppc(64) libsemanage-1.5.21-2.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 1.5.21-2.1 - bump again for double-long bug on ppc(64) * Fri Feb 10 2006 Dan Walsh - 1.5.21-2 - Fix handling of seusers and users_map file * Tue Feb 07 2006 Dan Walsh - 1.5.21-1 - Upgrade to latest from NSA * Merged seuser/user_extra support patch from Joshua Brindle. * Merged remote system dbase patch from Ivan Gyurdiev. libsepol-1.11.13-1.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 1.11.13-1.1 - bump again for double-long bug on ppc(64) libsetrans-0.1.18-1.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 0.1.18-1.2 - bump again for double-long bug on ppc(64) libsilc-0:0.9.12-12.2.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 0:0.9.12-12.2.1 - bump again for double-long bug on ppc(64) libsoup-2.2.7-1.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 2.2.7-1.2.1 - bump again for double-long bug on ppc(64) libstdc++so7-4.2.0-0.3.20060203.1 --------------------------------- * Fri Feb 10 2006 Jesse Keating - 4.2.0-0.3.20060203.1 - bump again for double-long bug on ppc(64) libtermcap-2.0.8-44.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 2.0.8-44.2 - bump again for double-long bug on ppc(64) libtheora-0:1.0alpha5-1.2.1 --------------------------- * Fri Feb 10 2006 Jesse Keating - 0:1.0alpha5-1.2.1 - bump again for double-long bug on ppc(64) libtiff-3.7.4-3.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 3.7.4-3.2.1 - bump again for double-long bug on ppc(64) libtool-1.5.22-2.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 1.5.22-2.2 - bump again for double-long bug on ppc(64) libusb-0.1.11-2.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 0.1.11-2.2 - bump again for double-long bug on ppc(64) libuser-0.54.3-1.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 0.54.3-1.2.1 - bump again for double-long bug on ppc(64) libvirt-0.0.4-1 --------------- * Fri Feb 10 2006 Daniel Veillard 0.0.4-1 - fixes some problems in 0.0.3 due to the change of names libvorbis-1:1.1.2-1.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 1:1.1.2-1.2 - bump again for double-long bug on ppc(64) libvte-java-0.11.11-8.2 ----------------------- * Fri Feb 10 2006 Jesse Keating - 0.11.11-8.2 - bump again for double-long bug on ppc(64) libwmf-0.2.8.4-4.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 0.2.8.4-4.2 - bump again for double-long bug on ppc(64) libwnck-2.13.90-1.2 ------------------- * Fri Feb 10 2006 Jesse Keating - 2.13.90-1.2 - bump again for double-long bug on ppc(64) libwpd-0.8.4-1.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 0.8.4-1.2.1 - bump again for double-long bug on ppc(64) libwvstreams-4.2.1-1.2 ---------------------- * Fri Feb 10 2006 Jesse Keating - 4.2.1-1.2 - bump again for double-long bug on ppc(64) libxkbfile-1.0.1-1.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1-1.2 - bump again for double-long bug on ppc(64) libxkbui-1.0.1-1.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 1.0.1-1.2 - bump again for double-long bug on ppc(64) libxklavier-2.1-3.2 ------------------- * Fri Feb 10 2006 Jesse Keating - 2.1-3.2 - bump again for double-long bug on ppc(64) libxml-1:1.8.17-13.2.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 1:1.8.17-13.2.1 - bump again for double-long bug on ppc(64) libxml2-2.6.23-1.2 ------------------ * Fri Feb 10 2006 Jesse Keating - 2.6.23-1.2 - bump again for double-long bug on ppc(64) libxslt-1.1.15-1.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 1.1.15-1.2.1 - bump again for double-long bug on ppc(64) linux-atm-2.5.0-0.20050118.3.2 ------------------------------ * Fri Feb 10 2006 Jesse Keating - 2.5.0-0.20050118.3.2 - bump again for double-long bug on ppc(64) linuxdoc-tools-0.9.21-6.2.1 --------------------------- * Fri Feb 10 2006 Jesse Keating - 0.9.21-6.2.1 - bump again for double-long bug on ppc(64) linuxwacom-0:0.7.2-1.2 ---------------------- * Fri Feb 10 2006 Jesse Keating - 0:0.7.2-1.2 - bump again for double-long bug on ppc(64) lksctp-tools-1.0.5-1.fc5.2 -------------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.5-1.fc5.2 - bump again for double-long bug on ppc(64) lm_sensors-2.9.2-1 ------------------ * Fri Feb 10 2006 Phil Knirsch 2.9.2-1 - Update to lm_sensors-2.9.2 - Fixed wrong subsys locking (#176965) - Removed lm_sensors pwmconfig, has been fixed upstream now lockdev-1.0.1-9.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 1.0.1-9.2.1 - bump again for double-long bug on ppc(64) logrotate-3.7.3-2.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 3.7.3-2.2.1 - bump again for double-long bug on ppc(64) lrzsz-0.12.20-21.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 0.12.20-21.2.1 - bump again for double-long bug on ppc(64) lslk-1.29-16.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.29-16.2.1 - bump again for double-long bug on ppc(64) lsof-4.76-1.2.1 --------------- * Fri Feb 10 2006 Jesse Keating - 4.76-1.2.1 - bump again for double-long bug on ppc(64) ltrace-0.3.36-4.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 0.3.36-4.2 - bump again for double-long bug on ppc(64) lv-4.51-7.2.1 ------------- * Fri Feb 10 2006 Jesse Keating - 4.51-7.2.1 - bump again for double-long bug on ppc(64) lvm2-2.02.01-1.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 2.02.01-1.2.1 - bump again for double-long bug on ppc(64) lynx-2.8.5-27.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 2.8.5-27.2.1 - bump again for double-long bug on ppc(64) m17n-lib-1.3.2-1.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 1.3.2-1.1 - bump again for double-long bug on ppc(64) m2crypto-0.15-3.2 ----------------- * Fri Feb 10 2006 Jesse Keating - 0.15-3.2 - bump again for double-long bug on ppc(64) m4-1.4.4-1.2.1 -------------- * Fri Feb 10 2006 Jesse Keating - 1.4.4-1.2.1 - bump again for double-long bug on ppc(64) macutils-2.0b3-32.2.1 --------------------- * Fri Feb 10 2006 Jesse Keating - 2.0b3-32.2.1 - bump again for double-long bug on ppc(64) magma-1.0.3-3.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 1.0.3-3.2.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 1.0.3-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 09 2005 Jesse Keating - rebuilt mailman-3:2.1.7-1.2 ------------------- * Fri Feb 10 2006 Jesse Keating - 3:2.1.7-1.2 - bump again for double-long bug on ppc(64) mailx-8.1.1-44.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 8.1.1-44.2.1 - bump again for double-long bug on ppc(64) make-1:3.80-10.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 1:3.80-10.2 - bump again for double-long bug on ppc(64) man-1.6c-1.2 ------------ * Fri Feb 10 2006 Jesse Keating - 1.6c-1.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 1.6c-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Thu Feb 02 2006 Florian La Roche - 1.6c mc-1:4.6.1a-7.2 --------------- * Fri Feb 10 2006 Jesse Keating - 1:4.6.1a-7.2 - bump again for double-long bug on ppc(64) mdadm-2.2-1.fc5.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 2.2-1.fc5.2.1 - bump again for double-long bug on ppc(64) mesa-6.4.2-2.1 -------------- * Fri Feb 10 2006 Jesse Keating - 6.4.2-2.1 - bump again for double-long bug on ppc(64) metacity-2.13.55-1.2 -------------------- * Fri Feb 10 2006 Jesse Keating - 2.13.55-1.2 - bump again for double-long bug on ppc(64) mgetty-1.1.33-7.FC5.2 --------------------- * Fri Feb 10 2006 Jesse Keating - 1.1.33-7.FC5.2 - bump again for double-long bug on ppc(64) mikmod-3.1.6-36.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 3.1.6-36.2.1 - bump again for double-long bug on ppc(64) mingetty-1.07-5.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 1.07-5.2.1 - bump again for double-long bug on ppc(64) minicom-2.1-1.2.1 ----------------- * Fri Feb 10 2006 Jesse Keating - 2.1-1.2.1 - bump again for double-long bug on ppc(64) mktemp-3:1.5-23.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 3:1.5-23.2.1 - bump again for double-long bug on ppc(64) mlocate-0.12-1.2 ---------------- * Fri Feb 10 2006 Jesse Keating - 0.12-1.2 - bump again for double-long bug on ppc(64) mod_auth_kerb-5.0-8.2.1 ----------------------- * Fri Feb 10 2006 Jesse Keating - 5.0-8.2.1 - bump again for double-long bug on ppc(64) mod_auth_mysql-1:3.0.0-2.2.1 ---------------------------- * Fri Feb 10 2006 Jesse Keating - 1:3.0.0-2.2.1 - bump again for double-long bug on ppc(64) mod_auth_pgsql-2.0.3-2.3 ------------------------ * Fri Feb 10 2006 Jesse Keating - 2.0.3-2.3 - bump again for double-long bug on ppc(64) mod_authz_ldap-0.26-6.2.1 ------------------------- * Fri Feb 10 2006 Jesse Keating - 0.26-6.2.1 - bump again for double-long bug on ppc(64) mod_perl-2.0.2-5.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 2.0.2-5.1 - bump again for double-long bug on ppc(64) module-init-tools-3.2-0.pre9.2.2 -------------------------------- * Fri Feb 10 2006 Jesse Keating - 3.2-0.pre9.2.2 - bump again for double-long bug on ppc(64) mono-1.1.13.2-2 --------------- * Sun Feb 12 2006 Christopher Aillon - 1.1.13.2-2 - Rebuild mozilla-37:1.7.12-5 ------------------- * Sun Feb 12 2006 Christopher Aillon - 37:1.7.12-5 - Update dumpstack.patch to match upstream mozplugger-1.7.3-2.2.1 ---------------------- * Fri Feb 10 2006 Jesse Keating - 1.7.3-2.2.1 - bump again for double-long bug on ppc(64) mpage-2.5.4-6.1 --------------- * Fri Feb 10 2006 Jesse Keating - 2.5.4-6.1 - bump again for double-long bug on ppc(64) mrtg-2.13.0-1.2 --------------- * Fri Feb 10 2006 Jesse Keating - 2.13.0-1.2 - bump again for double-long bug on ppc(64) mt-st-0.9b-2.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 0.9b-2.2.1 - bump again for double-long bug on ppc(64) mtools-3.9.10-1.2.1 ------------------- * Fri Feb 10 2006 Jesse Keating - 3.9.10-1.2.1 - bump again for double-long bug on ppc(64) mtr-2:0.69-7.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 2:0.69-7.2.1 - bump again for double-long bug on ppc(64) mtx-1.2.18-8.2.1 ---------------- * Fri Feb 10 2006 Jesse Keating - 1.2.18-8.2.1 - bump again for double-long bug on ppc(64) mutt-5:1.4.2.1-6.2.1 -------------------- * Fri Feb 10 2006 Jesse Keating - 5:1.4.2.1-6.2.1 - bump again for double-long bug on ppc(64) mx-2.0.6-2.2.1 -------------- * Fri Feb 10 2006 Jesse Keating - 2.0.6-2.2.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 2.0.6-2.2 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 09 2005 Jesse Keating - rebuilt mx4j-1:3.0.1-1jpp_9fc --------------------- * Fri Feb 10 2006 Jesse Keating - 1:3.0.1-1jpp_9fc - bump again for double-long bug on ppc(64) - rebuilt again Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 perl-suidperl - 4:5.8.8-2.1.i386 requires perl = 4:5.8.8-2 Broken deps for ia64 ---------------------------------------------------------- perl-suidperl - 4:5.8.8-2.1.ia64 requires perl = 4:5.8.8-2 rgmanager - 1.9.31-3.ia64 requires ccs vconfig - 1.9-1.1.ia64 requires libc.so.6 vconfig - 1.9-1.1.ia64 requires libc.so.6(GLIBC_2.0) Broken deps for ppc ---------------------------------------------------------- ccs-devel - 1.0.2-3.2.1.ppc requires ccs = 0:1.0.2-3.2.1 gulm - 1.0.0-2.ppc requires ccs perl-suidperl - 4:5.8.8-2.1.ppc requires perl = 4:5.8.8-2 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 magma-plugins - 1.0.3-1.FC5.ppc64 requires libgulm.so.1()(64bit) perl-suidperl - 4:5.8.8-2.1.ppc64 requires perl = 4:5.8.8-2 vconfig - 1.9-1.1.ppc64 requires libc.so.6 vconfig - 1.9-1.1.ppc64 requires libc.so.6(GLIBC_2.0) Broken deps for s390 ---------------------------------------------------------- perl-suidperl - 4:5.8.8-2.1.s390 requires perl = 4:5.8.8-2 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 Broken deps for s390x ---------------------------------------------------------- perl-suidperl - 4:5.8.8-2.1.s390x requires perl = 4:5.8.8-2 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 perl-suidperl - 4:5.8.8-2.1.x86_64 requires perl = 4:5.8.8-2 From jkeating at redhat.com Mon Feb 13 08:00:29 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 13 Feb 2006 00:00:29 -0800 Subject: rawhide report: 20060213 changes 2/2 In-Reply-To: <1139817191.31644.55.camel@ender> References: <200602130748.k1D7mQKs019059@porkchop.devel.redhat.com> <1139817191.31644.55.camel@ender> Message-ID: <1139817630.31644.57.camel@ender> On Sun, 2006-02-12 at 23:53 -0800, Jesse Keating wrote: > > Hrm. So the 1/2 message was still too big for mailman to accept. I'm > going to have to split it up even more. Sorry for the uglyness. > Actually no I won't. The list admin was able to push the larger email through. Enjoy! -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rhally at mindspring.com Mon Feb 13 08:10:02 2006 From: rhally at mindspring.com (Richard Hally) Date: Mon, 13 Feb 2006 03:10:02 -0500 Subject: rawhide report: 20060213 changes 2/2 In-Reply-To: <1139817630.31644.57.camel@ender> References: <200602130748.k1D7mQKs019059@porkchop.devel.redhat.com> <1139817191.31644.55.camel@ender> <1139817630.31644.57.camel@ender> Message-ID: <43F03EDA.2050803@mindspring.com> Jesse Keating wrote: > On Sun, 2006-02-12 at 23:53 -0800, Jesse Keating wrote: >> Hrm. So the 1/2 message was still too big for mailman to accept. I'm >> going to have to split it up even more. Sorry for the uglyness. >> > > Actually no I won't. The list admin was able to push the larger email > through. > > Enjoy! > > Nice work! Thanks for getting this whole thing behind us. From michael at knox.net.nz Mon Feb 13 08:40:13 2006 From: michael at knox.net.nz (Michael J Knox) Date: Mon, 13 Feb 2006 21:40:13 +1300 Subject: snort inline on Fedora In-Reply-To: <1139816754.2997.16.camel@laptopd505.fenrus.org> References: <1139796228.25720.9.camel@cosima.et.endace.com> <1139816258.2997.12.camel@laptopd505.fenrus.org> <1139816365.2681.0.camel@pingu.homenetwork.lan> <1139816754.2997.16.camel@laptopd505.fenrus.org> Message-ID: <1139820013.2681.6.camel@pingu.homenetwork.lan> On Mon, 2006-02-13 at 08:45 +0100, Arjan van de Ven wrote: > > > > So what would be the best way to "fix" this? > > > the latest snort just compiles for me... so maybe use that? > Ummm.. Are you enabling inline (--enable-inline)? The 2.4.3 release (current stable) and CVS head still fail with the below: In file included from /usr/include/linux/netfilter_ipv4/ip_queue.h:10, from /usr/include/libipq.h:37, from ../../src/inline.h:8, from ../../src/snort.h:36, from spo_alert_fast.c:51: /usr/include/linux/if.h:59: error: redefinition of ?struct ifmap? /usr/include/linux/if.h:77: error: redefinition of ?struct ifreq? /usr/include/linux/if.h:126: error: redefinition of ?struct ifconf? spo_alert_fast.c: In function ?AlertFastInit?: spo_alert_fast.c:124: warning: pointer targets in passing argument 1 of ?ParseAlertFastArgs? differ in signedness make[3]: *** [spo_alert_fast.o] Error 1 This is FC4 will all updates as of 20mins ago. Michael From hughsient at gmail.com Mon Feb 13 10:04:00 2006 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 13 Feb 2006 10:04:00 +0000 Subject: gnome-power-manager quits unexpectedly In-Reply-To: <4b3752c70602122012n73a21d1bic65b6c926247f8db@mail.gmail.com> References: <4b3752c70602122012n73a21d1bic65b6c926247f8db@mail.gmail.com> Message-ID: <15e53e180602130204r3ad5c492i@mail.gmail.com> On 13/02/06, S Baig wrote: > ** ERROR **: This program cannot start until you start the dbus session > daemon > This is usually started in X or gnome startup (depending on distro) > You can launch the session dbus-daemon manually with this command: > eval `dbus-launch --auto-syntax` > > > I cannot find 'dbus-launch' anywhere in my path, but I verified using > 'system-config-services' that the messagebus service is running. Has anyone > else had this problem? Do you have dbus-x11 installed? Richard. From naoki at valuecommerce.com Mon Feb 13 10:11:26 2006 From: naoki at valuecommerce.com (Naoki) Date: Mon, 13 Feb 2006 19:11:26 +0900 Subject: hypervisor-2.6.15-1.51_FC5 panics. Message-ID: <1139825486.2555.1.camel@dragon.sys.intra> >From a few days back and including latest rawhide kernel-xen-hypervisor-2.6.15-1.51_FC5 panics on boot. Do we know about this or should I bz it? Sorry I didn't get a look at the panic message because it reboots too quickly but it was not long after loading. From rmo at sunnmore.net Mon Feb 13 11:01:58 2006 From: rmo at sunnmore.net (Roy-Magne Mo) Date: Mon, 13 Feb 2006 12:01:58 +0100 Subject: hypervisor-2.6.15-1.51_FC5 panics. In-Reply-To: <1139825486.2555.1.camel@dragon.sys.intra> References: <1139825486.2555.1.camel@dragon.sys.intra> Message-ID: <1139828518.3131.26.camel@host-81-191-138-132.bluecom.no> m? den 13.02.2006 klokka 19:11 (+0900) skreiv Naoki: > >From a few days back and including latest rawhide > kernel-xen-hypervisor-2.6.15-1.51_FC5 panics on boot. > > Do we know about this or should I bz it? Sorry I didn't get a look at > the panic message because it reboots too quickly but it was not long > after loading. I'm seeing the same thing here with this hypervisor-kernel and the previous, kernel-xen-hypervisor-2.6.15-1.43_FC5, on at Compaq DL380 (dual PIII-866) at the point where XEN hands over output to det ordinary linux-kernel. kernel-xen-hypervisor-2.6.15-1.51_FC5 boots fine on my laptop though. Probably not much help, but hasn't gotten around to create a proper bugzilla yet. -- Roy-Magne Mo From ndbecker2 at gmail.com Mon Feb 13 12:03:10 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Mon, 13 Feb 2006 07:03:10 -0500 Subject: rawhide report: 20060213 changes 2/2 References: <200602130748.k1D7mQKs019059@porkchop.devel.redhat.com> Message-ID: Transaction Summary ============================================================================= Install 7 Package(s) Update 1243 Package(s) Remove 0 Package(s) Total download size: 1.5 G Is this ok [y/N]: OK, do I dare? Has anyone tried this massive update? Any good/bad reports? I saw a couple reports over the weekend of failures to start X. Not sure I want to try that experiment. From pbrobinson at gmail.com Mon Feb 13 12:09:18 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 13 Feb 2006 12:09:18 +0000 Subject: rawhide report: 20060213 changes 2/2 In-Reply-To: References: <200602130748.k1D7mQKs019059@porkchop.devel.redhat.com> Message-ID: <5256d0b0602130409l1424c059u9587041118ee4189@mail.gmail.com> On 2/13/06, Neal Becker wrote: > Transaction Summary > ============================================================================= > Install 7 Package(s) > Update 1243 Package(s) > Remove 0 Package(s) > Total download size: 1.5 G > Is this ok [y/N]: > > OK, do I dare? > > Has anyone tried this massive update? Any good/bad reports? > > I saw a couple reports over the weekend of failures to start X. Not sure I > want to try that experiment. I've already done it once with no problems. About 1/2 way through the install of the packages on this run. Most of the package updates are just recompiles, and for this second run only really effect ppc compared to the one done last week, so if you did the one last week with no troubles I wouldn't have thought this one would be either. Pete From fedora at camperquake.de Mon Feb 13 12:32:49 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 13 Feb 2006 13:32:49 +0100 Subject: rawhide report: 20060213 changes 2/2 In-Reply-To: References: <200602130748.k1D7mQKs019059@porkchop.devel.redhat.com> Message-ID: <20060213133249.0a421cf5@dhcp05.addix.net> Hi. On Mon, 13 Feb 2006 07:03:10 -0500, Neal Becker wrote: > OK, do I dare? > > Has anyone tried this massive update? Any good/bad reports? I did this after the last massive rebuild (for gcc4.1, I think). Took ages, but went without too much trouble. I also did this while in runlevel 1 (which revealed some interesing bugs on it's own). What is more interesting: is the rebuild finished now or are there still packages in the queue? From d.jacobfeuerborn at conversis.de Mon Feb 13 14:13:25 2006 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Mon, 13 Feb 2006 15:13:25 +0100 Subject: cron/dbus problem? Message-ID: <43F09405.5060206@conversis.de> Given the (puzzling) absence of an alarm/reminder applet for the gnome panel I tried (ab)using Tomboy for this purpose but hit a problem involving Cron and DBus. When I call "tomboy --open-note Alarm" the respective notes pops up but when I put the same command in the crontab I get this: Unhandled Exception: DBus.DBusException: Unable to determine the address of the message bus in <0x0009f> DBus.Bus:GetBus (BusType busType) in <0x00009> DBus.Bus:GetSessionBus () in <0x00022> Tomboy.TomboyCommandLine:Execute () in <0x00061> Tomboy.Tomboy:Main (System.String[] args) Does anyone have an idea why the session bus seems to be available from a regular shell but not from cron? Regards, Dennis From jeff at ocjtech.us Mon Feb 13 14:18:57 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Mon, 13 Feb 2006 08:18:57 -0600 Subject: cron/dbus problem? In-Reply-To: <43F09405.5060206@conversis.de> References: <43F09405.5060206@conversis.de> Message-ID: <1139840337.2801.11.camel@lt16585.campus.dmacc.edu> On Mon, 2006-02-13 at 15:13 +0100, Dennis Jacobfeuerborn wrote: > > Does anyone have an idea why the session bus seems to be available from a > regular shell but not from cron? Because the environment variable "DBUS_SESSION_BUS_ADDRESS" is set in a regular shell, but not from cron. 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 cra at WPI.EDU Mon Feb 13 14:35:30 2006 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 13 Feb 2006 09:35:30 -0500 Subject: snort inline on Fedora In-Reply-To: <1139796228.25720.9.camel@cosima.et.endace.com> References: <1139796228.25720.9.camel@cosima.et.endace.com> Message-ID: <20060213143530.GD5657@angus.ind.WPI.EDU> On Mon, Feb 13, 2006 at 03:03:48PM +1300, Michael J Knox wrote: > The suggestion is to point to a set of "real" kernel includes instead of > RH's glibc-kernheaders package. Kernel includes should never be used from userspace. > Has anyone got some suggestions on what should be done about this or how > to work around it (from a packaging standpoint) ? If the glibc-kernheaders are insufficient, and snort is sticking to documented public interfaces, then glibc-kernheaders should be fixed to define those interfaces. From jos at xos.nl Mon Feb 13 14:37:19 2006 From: jos at xos.nl (Jos Vos) Date: Mon, 13 Feb 2006 15:37:19 +0100 Subject: Missing files from kernel-xen-hypervisor-devel? Message-ID: <200602131437.k1DEbJf11863@xos037.xos.nl> Hi, When trying to build an external kernel module for kernel-xen-hypervisor (with kernel-xen-hypervisor-devel installed) I get: include/asm-i386/mach-xen/mach_page.h:10:31: xen/interface/xen.h: No such file or directory include/asm-i386/mach-xen/mach_page.h:11:30: xen/foreign_page.h: No such file or directory Should these files have been included with kernel-xen-hypervisor-devel? Note that the module I try to compile is something I probably won't need on a system with a Xen kernel, but this still might be a problem. I tried this with the 2.6.15-1.40_FC5 version of kernel-xen. Cheers, -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 13 15:04:47 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 13 Feb 2006 16:04:47 +0100 Subject: Autoconf configure script and X checking Message-ID: <20060213160447.305d9b2f@python2> Hi, This is something I've seen with synergy 1.2.7 which builds fine on FC4 and older : After an autoreconf on FC development, configure fails to detect X, the reason being : (sorry, some line breaks get mangled by sylpheed...) :^configure:5738: checking for X configure:5843: g++ -E conftest.cc configure:5849: $? = 0 configure:5899: g++ -o conftest -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -g conftest.cc -lXt >&5 /usr/include/X11/Xlib.h: In function 'int main()': /usr/include/X11/Xlib.h:1492: error: too many arguments to function 'void XrmInitialize()' conftest.cc:46: error: at this point in file configure:5905: $? = 1 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | #define PACKAGE "synergy" | #define VERSION "1.2.7" | #ifdef __cplusplus | extern "C" void std::exit (int) throw (); using std::exit; | #endif | #define HAVE_POSIX_SIGWAIT 1 | #define HAVE_PTHREAD_SIGNAL 1 | #define HAVE_PTHREAD 1 | #define HAVE_NANOSLEEP 1 | #define HAVE_INET_ATON 1 | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_SYS_TIME_H 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_LOCALE_H 1 | #define HAVE_WCHAR_H 1 | #define HAVE_ALLOCA_H 1 | #define HAVE_SYS_SOCKET_H 1 | #define HAVE_SYS_SELECT_H 1 | #define HAVE_SYS_UTSNAME_H 1 | #define HAVE_ISTREAM 1 | #define HAVE_OSTREAM 1 | #define HAVE_SSTREAM 1 | #define TIME_WITH_SYS_TIME 1 | /* end confdefs.h. */ | #include | int | main () | { | XrmInitialize (0) | ; | return 0; | } configure:5958: result: no After a quick glance, I see nothing weird in configure.in. Could this be related to the recent changes in X detection? (it used to be Intrinsic.h being checked IIRC). If this seems to be indeed an autoconf bug, I'll gladly report it in bugzilla. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.15-1.1831_FC4 Load : 0.87 0.78 0.51 From pozsy at uhulinux.hu Mon Feb 13 15:07:42 2006 From: pozsy at uhulinux.hu (Pozsar Balazs) Date: Mon, 13 Feb 2006 16:07:42 +0100 Subject: rawhide report: 20060210 changes (part 1/2) In-Reply-To: <1139595425.18359.14.camel@bree.local.net> References: <200602101257.k1ACviK4014258@porkchop.devel.redhat.com> <20060210180646.GA15822@ojjektum.uhulinux.hu> <1139595425.18359.14.camel@bree.local.net> Message-ID: <20060213150742.GA13236@ojjektum.uhulinux.hu> On Fri, Feb 10, 2006 at 01:17:05PM -0500, Jeremy Katz wrote: > On Fri, 2006-02-10 at 19:06 +0100, Pozsar Balazs wrote: > > On Fri, Feb 10, 2006 at 07:57:44AM -0500, Build System wrote: > > [...] > > > - rebuilt for new gcc4.1 snapshot and glibc changes > > [...] > > > > I am wondering long ago about these changelog entries... Why are > > rebuilds mentioned in the changelogs? Strictly speaking, these are not > > changes, at least not to the .src.rpm. > > Because otherwise, if I have foo-1.2.1-1 installed and see foo-1.2.1-2, > how do I know what changed without diffing src.rpms? That's what the > entire purpose of the changelog is. If foo-1.2.1-1.src.rpm is rebuilt, it could be versioned as foo-1.2.1-1.1, foo-1.2.1-1.2, foo-1.2.1-1.3 and so on. > > And by the way, I also fail to see why rebuilds are so special. Why > > aren't all packages rebuilt periodically by the build system? > > (Say, once a week or fortnight.) > > I think it can be easily seen that it would be a nice regular qa test, > > and also it would make sure that all gcc/glibc or any other > > library/compiler toolchain element changes/improvements would be > > propageted in regular and short timebase. > > There are more regular builds of everything for testing, but pushing > things out just ends up causing a lot more bandwidth usage than its > worth. Most packages get churned enough in the development tree that > any changes get propagated to packages quickly enough. Is bandwidth really a problem for fedora developers/testers? -- pozsy From katzj at redhat.com Mon Feb 13 15:48:42 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 13 Feb 2006 10:48:42 -0500 Subject: Missing files from kernel-xen-hypervisor-devel? In-Reply-To: <200602131437.k1DEbJf11863@xos037.xos.nl> References: <200602131437.k1DEbJf11863@xos037.xos.nl> Message-ID: <1139845722.28598.0.camel@orodruin.boston.redhat.com> On Mon, 2006-02-13 at 15:37 +0100, Jos Vos wrote: > When trying to build an external kernel module for kernel-xen-hypervisor > (with kernel-xen-hypervisor-devel installed) I get: > > include/asm-i386/mach-xen/mach_page.h:10:31: xen/interface/xen.h: No such file or directory > include/asm-i386/mach-xen/mach_page.h:11:30: xen/foreign_page.h: No such file or directory > > Should these files have been included with kernel-xen-hypervisor-devel? Yes, probably. Can you file a bug against the kernel-xen package so we don't lose this? Thanks, Jeremy From mailinglists at erwinrol.com Mon Feb 13 15:58:11 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Mon, 13 Feb 2006 16:58:11 +0100 Subject: HOWTO Debug apache+php ? Re: apache and phpldapconfig In-Reply-To: <1139785841.17385.25.camel@xpc.home.erwinrol.com> References: <1139785841.17385.25.camel@xpc.home.erwinrol.com> Message-ID: <1139846292.17385.90.camel@xpc.home.erwinrol.com> How can i debug apache running php that segfaults when i try to login with phpldapadmin ? - Erwin On Mon, 2006-02-13 at 00:10 +0100, Erwin Rol wrote: > I am trying to get phpldapconfig working and i have the following > problem. > > when loading the phpldapconfig page everything works fine, my "local > host" ldap server shows up, and i can click on "login". When i do that i > get the login "prompt" and fill out my login data, than press enter or > click the button, and than something strange happens, I get a file save > dialog asking me if i want to save login.php. If i check my apache > error_log i see that apache died with a sig 11. > > does anybody else have this problem ? > > - Erwin > > > [Mon Feb 13 00:05:36 2006] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) > [Mon Feb 13 00:05:36 2006] [info] Init: Seeding PRNG with 256 bytes of entropy > [Mon Feb 13 00:05:36 2006] [info] Init: Generating temporary RSA private keys (512/1024 bits) > [Mon Feb 13 00:05:37 2006] [info] Init: Generating temporary DH parameters (512/1024 bits) > [Mon Feb 13 00:05:37 2006] [info] Init: Initializing (virtual) servers for SSL > [Mon Feb 13 00:05:37 2006] [info] Server: Apache/2.2.0, Interface: mod_ssl/2.2.0, Library: OpenSSL/0.9.8a > [Mon Feb 13 00:05:37 2006] [notice] Digest: generating secret for digest authentication ... > [Mon Feb 13 00:05:37 2006] [notice] Digest: done > [Mon Feb 13 00:05:37 2006] [debug] util_ldap.c(1873): LDAP merging Shared Cache conf: shm=0x5555557a4258 rmm=0x5555557a4290 for VHOST: xpc.home.erwinrol.com > [Mon Feb 13 00:05:37 2006] [info] APR LDAP: Built with OpenLDAP LDAP SDK > [Mon Feb 13 00:05:37 2006] [info] LDAP: SSL support available > [Mon Feb 13 00:05:37 2006] [info] Init: Seeding PRNG with 256 bytes of entropy > [Mon Feb 13 00:05:37 2006] [info] Init: Generating temporary RSA private keys (512/1024 bits) > [Mon Feb 13 00:05:37 2006] [info] Init: Generating temporary DH parameters (512/1024 bits) > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(369): shmcb_init allocated 512000 bytes of shared memory > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(549): entered shmcb_init_memory() > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(571): for 512000 bytes, recommending 4265 indexes > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(614): shmcb_init_memory choices follow > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(616): division_mask = 0x1F > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(618): division_offset = 96 > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(620): division_size = 15997 > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(622): queue_size = 2136 > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(624): index_num = 133 > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(626): index_offset = 8 > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(628): index_size = 16 > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(630): cache_data_offset = 8 > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(632): cache_data_size = 13853 > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(645): leaving shmcb_init_memory() > [Mon Feb 13 00:05:37 2006] [info] Shared memory session cache initialised > [Mon Feb 13 00:05:37 2006] [info] Init: Initializing (virtual) servers for SSL > [Mon Feb 13 00:05:37 2006] [info] Server: Apache/2.2.0, Interface: mod_ssl/2.2.0, Library: OpenSSL/0.9.8a > [Mon Feb 13 00:05:37 2006] [debug] proxy_util.c(1681): proxy: initialized single connection worker 0 in child 22171 for (*) > [Mon Feb 13 00:05:37 2006] [notice] Apache/2.2.0 (Fedora) configured -- resuming normal operations > [Mon Feb 13 00:05:37 2006] [info] Server built: Feb 8 2006 03:09:46 > [Mon Feb 13 00:05:37 2006] [debug] prefork.c(991): AcceptMutex: sysvsem (default: sysvsem) > [Mon Feb 13 00:05:58 2006] [notice] child pid 22175 exit signal Segmentation fault (11) > > From d.jacobfeuerborn at conversis.de Mon Feb 13 15:08:05 2006 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Mon, 13 Feb 2006 16:08:05 +0100 Subject: cron/dbus problem? In-Reply-To: <1139840337.2801.11.camel@lt16585.campus.dmacc.edu> References: <43F09405.5060206@conversis.de> <1139840337.2801.11.camel@lt16585.campus.dmacc.edu> Message-ID: <43F0A0D5.9050107@conversis.de> Jeffrey C. Ollie wrote: > On Mon, 2006-02-13 at 15:13 +0100, Dennis Jacobfeuerborn wrote: >> Does anyone have an idea why the session bus seems to be available from a >> regular shell but not from cron? > > Because the environment variable "DBUS_SESSION_BUS_ADDRESS" is set in a > regular shell, but not from cron. Shouldn't this be considered a bug? What I was trying to do doesn't seem like a weird use case so I believe it should be possible to use DBus from cron like that. Regards, Dennis From rc040203 at freenet.de Mon Feb 13 16:17:23 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 13 Feb 2006 17:17:23 +0100 Subject: Autoconf configure script and X checking In-Reply-To: <20060213160447.305d9b2f@python2> References: <20060213160447.305d9b2f@python2> Message-ID: <1139847443.12023.221.camel@mccallum.corsepiu.local> On Mon, 2006-02-13 at 16:04 +0100, Matthias Saou wrote: > Hi, > > This is something I've seen with synergy 1.2.7 which builds fine on FC4 > and older : After an autoreconf on FC development, configure fails to > detect X, the reason being : > > (sorry, some line breaks get mangled by sylpheed...) > > :^configure:5738: checking for X > configure:5843: g++ -E conftest.cc > configure:5849: $? = 0 > configure:5899: g++ -o conftest -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 > -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 > -mtune=generic -g conftest.cc -lXt >&5 /usr/include/X11/Xlib.h: In > function 'int main()': /usr/include/X11/Xlib.h:1492: error: too many > arguments to function 'void XrmInitialize()' conftest.cc:46: error: at > this point in file configure:5905: $? = 1 configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "synergy" > | #define VERSION "1.2.7" > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | #define HAVE_POSIX_SIGWAIT 1 > | #define HAVE_PTHREAD_SIGNAL 1 > | #define HAVE_PTHREAD 1 > | #define HAVE_NANOSLEEP 1 > | #define HAVE_INET_ATON 1 > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_SYS_TIME_H 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_LOCALE_H 1 > | #define HAVE_WCHAR_H 1 > | #define HAVE_ALLOCA_H 1 > | #define HAVE_SYS_SOCKET_H 1 > | #define HAVE_SYS_SELECT_H 1 > | #define HAVE_SYS_UTSNAME_H 1 > | #define HAVE_ISTREAM 1 > | #define HAVE_OSTREAM 1 > | #define HAVE_SSTREAM 1 > | #define TIME_WITH_SYS_TIME 1 > | /* end confdefs.h. */ > | #include > | int > | main () > | { > | XrmInitialize (0) > | ; > | return 0; > | } > configure:5958: result: no > > After a quick glance, I see nothing weird in configure.in. Could this be > related to the recent changes in X detection? (it used to be Intrinsic.h > being checked IIRC). Yes. > If this seems to be indeed an autoconf bug, It's a bug in RH's change. Xlib.h contains this prototypes: void XrmInitialize( void ); But their hack bogusly assumes: void XrmInitialize( int ); > I'll gladly report it in bugzilla. Please do so. IMO, their change is harmful, but that's not your problem, here. They simply screwed it. Ralf From jos at xos.nl Mon Feb 13 16:22:09 2006 From: jos at xos.nl (Jos Vos) Date: Mon, 13 Feb 2006 17:22:09 +0100 Subject: Missing files from kernel-xen-hypervisor-devel? In-Reply-To: <1139845722.28598.0.camel@orodruin.boston.redhat.com>; from katzj@redhat.com on Mon, Feb 13, 2006 at 10:48:42AM -0500 References: <200602131437.k1DEbJf11863@xos037.xos.nl> <1139845722.28598.0.camel@orodruin.boston.redhat.com> Message-ID: <20060213172209.A12382@xos037.xos.nl> On Mon, Feb 13, 2006 at 10:48:42AM -0500, Jeremy Katz wrote: > Yes, probably. Can you file a bug against the kernel-xen package so we > don't lose this? Done: Bugzilla bug #181338. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 13 16:35:13 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 13 Feb 2006 17:35:13 +0100 Subject: Autoconf configure script and X checking In-Reply-To: <1139847443.12023.221.camel@mccallum.corsepiu.local> References: <20060213160447.305d9b2f@python2> <1139847443.12023.221.camel@mccallum.corsepiu.local> Message-ID: <20060213173513.6622c177@python2> Ralf Corsepius wrote : > It's a bug in RH's change. > > Xlib.h contains this prototypes: > void XrmInitialize( void ); > > But their hack bogusly assumes: > void XrmInitialize( int ); > > > > I'll gladly report it in bugzilla. > Please do so. > > IMO, their change is harmful, but that's not your problem, here. They > simply screwed it. Thanks :-) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181340 Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.15-1.1831_FC4 Load : 0.23 0.22 0.16 From czubeldia at deteagrupo.es Mon Feb 13 15:54:45 2006 From: czubeldia at deteagrupo.es (Carmelo Zubeldia) Date: Mon, 13 Feb 2006 16:54:45 +0100 Subject: HOWTO Debug apache+php ? Re: apache and phpldapconfig In-Reply-To: <1139846292.17385.90.camel@xpc.home.erwinrol.com> References: <1139785841.17385.25.camel@xpc.home.erwinrol.com> <1139846292.17385.90.camel@xpc.home.erwinrol.com> Message-ID: <1139846085.4774.27.camel@gddgda> strace -p $PID El lun, 13-02-2006 a las 16:58 +0100, Erwin Rol escribi?: > How can i debug apache running php that segfaults when i try to login > with phpldapadmin ? > > - Erwin > > On Mon, 2006-02-13 at 00:10 +0100, Erwin Rol wrote: > > I am trying to get phpldapconfig working and i have the following > > problem. > > > > when loading the phpldapconfig page everything works fine, my > "local > > host" ldap server shows up, and i can click on "login". When i do > that i > > get the login "prompt" and fill out my login data, than press enter > or > > click the button, and than something strange happens, I get a file > save > > dialog asking me if i want to save login.php. If i check my apache > > error_log i see that apache died with a sig 11. > > > > does anybody else have this problem ? > > > > - Erwin > > > > > > [Mon Feb 13 00:05:36 2006] [notice] suEXEC mechanism enabled > (wrapper: /usr/sbin/suexec) > > [Mon Feb 13 00:05:36 2006] [info] Init: Seeding PRNG with 256 bytes > of entropy > > [Mon Feb 13 00:05:36 2006] [info] Init: Generating temporary RSA > private keys (512/1024 bits) > > [Mon Feb 13 00:05:37 2006] [info] Init: Generating temporary DH > parameters (512/1024 bits) > > [Mon Feb 13 00:05:37 2006] [info] Init: Initializing (virtual) > servers for SSL > > [Mon Feb 13 00:05:37 2006] [info] Server: Apache/2.2.0, Interface: > mod_ssl/2.2.0, Library: OpenSSL/0.9.8a > > [Mon Feb 13 00:05:37 2006] [notice] Digest: generating secret for > digest authentication ... > > [Mon Feb 13 00:05:37 2006] [notice] Digest: done > > [Mon Feb 13 00:05:37 2006] [debug] util_ldap.c(1873): LDAP merging > Shared Cache conf: shm=0x5555557a4258 rmm=0x5555557a4290 for VHOST: > xpc.home.erwinrol.com > > > [Mon Feb 13 00:05:37 2006] [info] APR LDAP: Built with OpenLDAP LDAP > SDK > > [Mon Feb 13 00:05:37 2006] [info] LDAP: SSL support available > > [Mon Feb 13 00:05:37 2006] [info] Init: Seeding PRNG with 256 bytes > of entropy > > [Mon Feb 13 00:05:37 2006] [info] Init: Generating temporary RSA > private keys (512/1024 bits) > > [Mon Feb 13 00:05:37 2006] [info] Init: Generating temporary DH > parameters (512/1024 bits) > > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(369): > shmcb_init allocated 512000 bytes of shared memory > > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(549): entered > shmcb_init_memory() > > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(571): for > 512000 bytes, recommending 4265 indexes > > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(614): > shmcb_init_memory choices follow > > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(616): > division_mask = 0x1F > > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(618): > division_offset = 96 > > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(620): > division_size = 15997 > > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(622): > queue_size = 2136 > > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(624): > index_num = 133 > > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(626): > index_offset = 8 > > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(628): > index_size = 16 > > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(630): > cache_data_offset = 8 > > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(632): > cache_data_size = 13853 > > [Mon Feb 13 00:05:37 2006] [debug] ssl_scache_shmcb.c(645): leaving > shmcb_init_memory() > > [Mon Feb 13 00:05:37 2006] [info] Shared memory session cache > initialised > > [Mon Feb 13 00:05:37 2006] [info] Init: Initializing (virtual) > servers for SSL > > [Mon Feb 13 00:05:37 2006] [info] Server: Apache/2.2.0, Interface: > mod_ssl/2.2.0, Library: OpenSSL/0.9.8a > > [Mon Feb 13 00:05:37 2006] [debug] proxy_util.c(1681): proxy: > initialized single connection worker 0 in child 22171 for (*) > > > [Mon Feb 13 00:05:37 2006] [notice] Apache/2.2.0 (Fedora) configured > -- resuming normal operations > > [Mon Feb 13 00:05:37 2006] [info] Server built: Feb 8 2006 > 03:09:46 > > [Mon Feb 13 00:05:37 2006] [debug] prefork.c(991): AcceptMutex: > sysvsem (default: sysvsem) > > [Mon Feb 13 00:05:58 2006] [notice] child pid 22175 exit signal > Segmentation fault (11) > > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From caillon at redhat.com Mon Feb 13 16:38:18 2006 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 13 Feb 2006 11:38:18 -0500 Subject: rawhide report: 20060213 changes 2/2 In-Reply-To: <20060213133249.0a421cf5@dhcp05.addix.net> References: <200602130748.k1D7mQKs019059@porkchop.devel.redhat.com> <20060213133249.0a421cf5@dhcp05.addix.net> Message-ID: <43F0B5FA.1090204@redhat.com> On 02/13/2006 07:32 AM, Ralf Ertzinger wrote: > Hi. > > On Mon, 13 Feb 2006 07:03:10 -0500, Neal Becker wrote: > >> OK, do I dare? >> >> Has anyone tried this massive update? Any good/bad reports? > > I did this after the last massive rebuild (for gcc4.1, I think). > Took ages, but went without too much trouble. I also did this while > in runlevel 1 (which revealed some interesing bugs on it's own). > > What is more interesting: is the rebuild finished now or are there > still packages in the queue? I think its mostly done, although I heard there may be about 20 packages that need a third rebuild because of the way the builds were done (packages may have linked against static libraries that weren't yet rebuilt at the time) From clumens at redhat.com Mon Feb 13 16:42:48 2006 From: clumens at redhat.com (Chris Lumens) Date: Mon, 13 Feb 2006 11:42:48 -0500 Subject: Today's anaconda refuses to partition my disk In-Reply-To: References: Message-ID: <20060213164248.GA2978@exeter.boston.redhat.com> > bootloader --location=mbr > clearpart --linux --drives=hda > part /boot --fstype ext3 --size=50 > part pv.1 --size 4800 --grow > volgroup rootvg pv.1 > logvol / --vgname=rootvg --size=512 --name=root > logvol swap --fstype=swap --vgname=rootvg --recommended --name=swap > logvol /usr --vgname=rootvg --size=4000 --name=usr > logvol /var --vgname=rootvg --size=256 --name=var > logvol /export/data1 --vgname=rootvg --size=1 --name=data1 --grow > > anaconda.log: > 14:33:57 DEBUG : self.driveList(): ['hda'] > 14:33:57 DEBUG : DiskSet.skippedDisks: [] > 14:33:57 DEBUG : DiskSet.skippedDisks: [] > 14:33:57 DEBUG : starting all dmraids on drives ['hda'] > 14:33:57 DEBUG : scanning for dmraid on drives ['hda'] > 14:33:58 WARNING : Requested resolution 1600x1200 is not supported, > falling back to 800x6 > 00. To avoid this you may need to specify the videocard and monitor > specs on the xconfig > ks directive if they were not probed correctly. > 14:33:58 INFO : Detected 2032M of memory > 14:33:58 INFO : Swap attempt of 1000M to 2000M > 14:33:58 WARNING : step partitionmethod does not exist > 14:33:58 WARNING : step partitionmethodsetup does not exist > 14:33:58 WARNING : step autopartition does not exist > 14:33:58 WARNING : step readcomps does not exist > 14:33:58 WARNING : step selectlangpackages does not exist > 14:33:58 WARNING : step handleX11pkgs does not exist > 14:33:58 WARNING : step handlemiscpkgs does not exist > 14:33:58 WARNING : step fixupconditionals does not exist > 14:33:58 WARNING : step complete does not exist > 14:33:58 WARNING : step complete does not exist > 14:33:58 WARNING : step complete does not exist > 14:33:58 WARNING : step complete does not exist > 14:33:58 WARNING : step complete does not exist > 14:33:58 WARNING : step complete does not exist > 14:33:58 WARNING : step complete does not exist > 14:33:58 INFO : moving (1) to step partitionobjinit > 14:33:58 DEBUG : self.driveList(): ['hda'] > 14:33:58 DEBUG : DiskSet.skippedDisks: [] > 14:33:58 DEBUG : DiskSet.skippedDisks: [] > 14:33:58 INFO : moving (1) to step autopartitionexecute > 14:33:59 DEBUG : self.driveList(): ['hda'] > 14:33:59 DEBUG : DiskSet.skippedDisks: [] > 14:33:59 DEBUG : DiskSet.skippedDisks: [] Please file a bug with your kickstart file and whatever error message you're getting on the screen and I'll look at it. Might be a pykickstart bug. - Chris From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 13 16:43:14 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 13 Feb 2006 17:43:14 +0100 Subject: HOWTO Debug apache+php ? Re: apache and phpldapconfig In-Reply-To: <1139846292.17385.90.camel@xpc.home.erwinrol.com> References: <1139785841.17385.25.camel@xpc.home.erwinrol.com> <1139846292.17385.90.camel@xpc.home.erwinrol.com> Message-ID: <20060213174314.00634cba@python2> Erwin Rol wrote : > How can i debug apache running php that segfaults when i try to login > with phpldapadmin ? Add a line "CoreDumpDirectory /tmp" somewhere in your apache configuration. Then install the debuginfo packages you need and fire up gdb on the core files you'll have. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.15-1.1831_FC4 Load : 0.82 0.61 0.34 From johnp at redhat.com Mon Feb 13 16:51:32 2006 From: johnp at redhat.com (John (J5) Palmieri) Date: Mon, 13 Feb 2006 11:51:32 -0500 Subject: cron/dbus problem? In-Reply-To: <43F0A0D5.9050107@conversis.de> References: <43F09405.5060206@conversis.de> <1139840337.2801.11.camel@lt16585.campus.dmacc.edu> <43F0A0D5.9050107@conversis.de> Message-ID: <1139849492.30456.4.camel@remedyz.boston.redhat.com> On Mon, 2006-02-13 at 16:08 +0100, Dennis Jacobfeuerborn wrote: > Jeffrey C. Ollie wrote: > > On Mon, 2006-02-13 at 15:13 +0100, Dennis Jacobfeuerborn wrote: > >> Does anyone have an idea why the session bus seems to be available from a > >> regular shell but not from cron? > > > > Because the environment variable "DBUS_SESSION_BUS_ADDRESS" is set in a > > regular shell, but not from cron. > > Shouldn't this be considered a bug? What I was trying to do doesn't seem > like a weird use case so I believe it should be possible to use DBus from > cron like that. And what if your session isn't running or you are running more than one session? Which bus does the cron job attach to? -- John (J5) Palmieri From jspaleta at gmail.com Mon Feb 13 16:56:16 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 13 Feb 2006 11:56:16 -0500 Subject: cron/dbus problem? In-Reply-To: <1139849492.30456.4.camel@remedyz.boston.redhat.com> References: <43F09405.5060206@conversis.de> <1139840337.2801.11.camel@lt16585.campus.dmacc.edu> <43F0A0D5.9050107@conversis.de> <1139849492.30456.4.camel@remedyz.boston.redhat.com> Message-ID: <604aa7910602130856o77637171neeb1d1c0af43d519@mail.gmail.com> On 2/13/06, John (J5) Palmieri wrote: > And what if your session isn't running or you are running more than one > session? Which bus does the cron job attach to? is the solution to the precieved problem in this thread "oddjob"? http://people.redhat.com/nalin/oddjob/ -jef"I'm such a slacker.. i need to find time to finish that review off so it can get published in Extras for FC5"spaleta From jeff at ocjtech.us Mon Feb 13 16:58:32 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Mon, 13 Feb 2006 10:58:32 -0600 Subject: cron/dbus problem? In-Reply-To: <43F0A0D5.9050107@conversis.de> References: <43F09405.5060206@conversis.de> <1139840337.2801.11.camel@lt16585.campus.dmacc.edu> <43F0A0D5.9050107@conversis.de> Message-ID: <1139849912.2801.33.camel@lt16585.campus.dmacc.edu> On Mon, 2006-02-13 at 16:08 +0100, Dennis Jacobfeuerborn wrote: > Jeffrey C. Ollie wrote: > > On Mon, 2006-02-13 at 15:13 +0100, Dennis Jacobfeuerborn wrote: > >> Does anyone have an idea why the session bus seems to be available from a > >> regular shell but not from cron? > > > > Because the environment variable "DBUS_SESSION_BUS_ADDRESS" is set in a > > regular shell, but not from cron. > > Shouldn't this be considered a bug? I don't think so. The session bus is meant to be used by programs started from the current console session. Programs started from cron aren't part of the current console session. In fact, there may not even *be* a session when cron runs your program. > What I was trying to do doesn't seem > like a weird use case so I believe it should be possible to use DBus from > cron like that. I think that the developers have indicated that the solution is to create some sort of proxy. I haven't done any developing with DBus but I would think that it would be relatively easy to write a little process that listens to both the system bus and the session bus and proxies messages between them. Depending on the messages you want to send SELinux might get in your way, but that's not an insurmountable problem. 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 bojan at rexursive.com Mon Feb 13 19:05:55 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 14 Feb 2006 06:05:55 +1100 Subject: GDM Message-ID: <1139857556.2578.3.camel@beast.rexursive.com> Is it just my box or did others see breakage of GDM with the latest jumbo update? For whatever reason, it wants to start a "Failsafe GNOME session" now (it claims that it cannot find or run the base session script). I'm also getting gdmsetup do "double free or corruption"... Any ideas? -- Bojan From sdl.web at gmail.com Mon Feb 13 19:43:29 2006 From: sdl.web at gmail.com (leon) Date: Mon, 13 Feb 2006 19:43:29 +0000 Subject: two version of the same apps installed, bug? Message-ID: Hi guys, I found that my system running fedora rawhide has a weird thing, for example, 'rpm -qa|grep -i file|sort' gives: audiofile-0.2.6-2.1 audiofile-0.2.6-2.2.1 desktop-file-utils-0.10-4 desktop-file-utils-0.10-6.1 file-4.16-5 file-4.16-6.2 file-roller-2.13.90-1 filesystem-2.3.7-1.1 filesystem-2.3.7-1.2.1 libxkbfile-1.0.1-1 libxkbfile-1.0.1-1.2 rootfiles-8.1-1.1 xorg-x11-filesystem-0.99.2-3 xorg-x11-filesystem-7.0-1 Is it this a bug or a new feature of yum? Thanks. -- Leon From rstrode at redhat.com Mon Feb 13 19:47:49 2006 From: rstrode at redhat.com (Ray Strode) Date: Mon, 13 Feb 2006 14:47:49 -0500 Subject: GDM In-Reply-To: <1139857556.2578.3.camel@beast.rexursive.com> References: <1139857556.2578.3.camel@beast.rexursive.com> Message-ID: <1139860070.2587.4.camel@halflap> Hi, > Is it just my box or did others see breakage of GDM with the latest > jumbo update? For whatever reason, it wants to start a "Failsafe GNOME > session" now (it claims that it cannot find or run the base session > script). I'm also getting gdmsetup do "double free or corruption"... This should be fixed in tomorrow's rawhide. In the mean time, sed -i -e 's@/etc/X11/gdm@/etc/gdm at g' /etc/gdm/custom.conf should fix things up --Ray From linux_4ever at yahoo.com Mon Feb 13 19:52:40 2006 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 13 Feb 2006 11:52:40 -0800 (PST) Subject: two version of the same apps installed, bug? In-Reply-To: Message-ID: <20060213195240.80489.qmail@web51514.mail.yahoo.com> >Is it this a bug or a new feature of yum? This can happen for a variety of reasons. For example, SE linux can cause problems if you are using rawhide; yum may have had a bug on one day that didn't let it clean up, etc. I posted a shell script last week that finds this problem and another one if you are on a multilib platform. You can find it here: https://www.redhat.com/archives/fedora-test-list/2006-February/msg00430.html -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From paul at cypherpunks.ca Mon Feb 13 20:20:13 2006 From: paul at cypherpunks.ca (Paul Wouters) Date: Mon, 13 Feb 2006 21:20:13 +0100 (CET) Subject: two version of the same apps installed, bug? In-Reply-To: References: Message-ID: On Mon, 13 Feb 2006, leon wrote: > I found that my system running fedora rawhide has a weird thing, for > example, 'rpm -qa|grep -i file|sort' gives: You're running on an AMD64 using multilib with some 32bit rpms? Paul From tjb at unh.edu Mon Feb 13 20:16:10 2006 From: tjb at unh.edu (Thomas J. Baker) Date: Mon, 13 Feb 2006 15:16:10 -0500 Subject: GDM In-Reply-To: <1139860070.2587.4.camel@halflap> References: <1139857556.2578.3.camel@beast.rexursive.com> <1139860070.2587.4.camel@halflap> Message-ID: <1139861771.16457.2.camel@intrepid> On Mon, 2006-02-13 at 14:47 -0500, Ray Strode wrote: > Hi, > > Is it just my box or did others see breakage of GDM with the latest > > jumbo update? For whatever reason, it wants to start a "Failsafe GNOME > > session" now (it claims that it cannot find or run the base session > > script). I'm also getting gdmsetup do "double free or corruption"... > This should be fixed in tomorrow's rawhide. In the mean time, > > sed -i -e 's@/etc/X11/gdm@/etc/gdm at g' /etc/gdm/custom.conf > > should fix things up > > --Ray > I'm running gdm-2.13.0.7.0.2006.02.12-1 and the /etc/gdm/custom.conf is essentially empty (blank sections for daemon, security, etc.). I can't log in at all as a normal user although root can. Your sed substitution fails to match anything. Any ideas? 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 rowan at stasis.org Mon Feb 13 20:37:27 2006 From: rowan at stasis.org (Rowan Kerr) Date: Mon, 13 Feb 2006 15:37:27 -0500 Subject: gnome-power-manager quits unexpectedly In-Reply-To: <15e53e180602130204r3ad5c492i@mail.gmail.com> References: <4b3752c70602122012n73a21d1bic65b6c926247f8db@mail.gmail.com> <15e53e180602130204r3ad5c492i@mail.gmail.com> Message-ID: <43F0EE07.1070501@stasis.org> Richard Hughes wrote: > On 13/02/06, S Baig wrote: >> ** ERROR **: This program cannot start until you start the dbus session >> daemon >> This is usually started in X or gnome startup (depending on distro) >> You can launch the session dbus-daemon manually with this command: >> eval `dbus-launch --auto-syntax` >> >> >> I cannot find 'dbus-launch' anywhere in my path, but I verified using >> 'system-config-services' that the messagebus service is running. Has anyone >> else had this problem? > > Do you have dbus-x11 installed? I get the same problem persistently since installing from fc5t2 and upgrading to rawhide. (I just did another update this morning). dbus-x11 is: dbux-x11-0.60-7.2 and messagebus is set to run on startup. I get another message about selinux: ** (gnome-power-manager:2347):WARNING **: main: an SELinux policy prevents this sender from sending this message... (rejected message had interface "org.freedesktop.DBus" member "Hello" error name "(unset") destination "org.freedeesktop.DBus") Is there somewhere I should be resetting my selinux config or what.. From mailinglists at erwinrol.com Mon Feb 13 21:14:14 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Mon, 13 Feb 2006 22:14:14 +0100 Subject: HOWTO Debug apache+php ? Re: apache and phpldapconfig In-Reply-To: <20060213174314.00634cba@python2> References: <1139785841.17385.25.camel@xpc.home.erwinrol.com> <1139846292.17385.90.camel@xpc.home.erwinrol.com> <20060213174314.00634cba@python2> Message-ID: <1139865254.17385.106.camel@xpc.home.erwinrol.com> On Mon, 2006-02-13 at 17:43 +0100, Matthias Saou wrote: > Add a line "CoreDumpDirectory /tmp" somewhere in your apache > configuration. Then install the debuginfo packages you need and fire up > gdb on the core files you'll have. OK that was what i was looking for. Thanks, Erwin From tjb at unh.edu Mon Feb 13 21:13:46 2006 From: tjb at unh.edu (Thomas J. Baker) Date: Mon, 13 Feb 2006 16:13:46 -0500 Subject: GDM In-Reply-To: <1139861771.16457.2.camel@intrepid> References: <1139857556.2578.3.camel@beast.rexursive.com> <1139860070.2587.4.camel@halflap> <1139861771.16457.2.camel@intrepid> Message-ID: <1139865227.16457.7.camel@intrepid> On Mon, 2006-02-13 at 15:16 -0500, Thomas J. Baker wrote: > On Mon, 2006-02-13 at 14:47 -0500, Ray Strode wrote: > > Hi, > > > Is it just my box or did others see breakage of GDM with the latest > > > jumbo update? For whatever reason, it wants to start a "Failsafe GNOME > > > session" now (it claims that it cannot find or run the base session > > > script). I'm also getting gdmsetup do "double free or corruption"... > > This should be fixed in tomorrow's rawhide. In the mean time, > > > > sed -i -e 's@/etc/X11/gdm@/etc/gdm at g' /etc/gdm/custom.conf > > > > should fix things up > > > > --Ray > > > > I'm running gdm-2.13.0.7.0.2006.02.12-1 and the /etc/gdm/custom.conf is > essentially empty (blank sections for daemon, security, etc.). I can't > log in at all as a normal user although root can. Your sed substitution > fails to match anything. > > Any ideas? > > tjb It doesn't appear my problems are related to gdm. Even at runlevel 3, startx bombs out too. The biggest suck is that there don't seem to be any error messages anywhere... 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 mailinglists at erwinrol.com Mon Feb 13 21:16:31 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Mon, 13 Feb 2006 22:16:31 +0100 Subject: openldap runuser In-Reply-To: <20060212195212.GA8069@redhat.com> References: <1139766204.15597.1.camel@xpc.home.erwinrol.com> <20060212195212.GA8069@redhat.com> Message-ID: <1139865391.17385.108.camel@xpc.home.erwinrol.com> On Sun, 2006-02-12 at 14:52 -0500, Jay Fenlason wrote: > On Sun, Feb 12, 2006 at 06:43:24PM +0100, Erwin Rol wrote: > > Hey all, > > > > I am trying to get openldap running, but when i start it i get the > > following error: > > > > [root at xpc etc]# /etc/init.d/ldap start > > Checking configuration files for slapd: /sbin/runuser: invalid option -- u > > Try `/sbin/runuser --help' for more information. > > [FAILED] > > > > Is this a real bug in the init script, or am i just doing something wrong ? > > It's a bug. I tried to fix it, but it's still not working right. > I'll push through a new OpenLDAP after the current mass rebuild is > done. Today's version works. - Erwin From fedora at soeterbroek.com Mon Feb 13 21:18:25 2006 From: fedora at soeterbroek.com (Joost Soeterbroek) Date: Mon, 13 Feb 2006 22:18:25 +0100 Subject: Linux-HA? Message-ID: <1139865505.21582.10.camel@alexandria> Naoki wrote: > Hey all, > > Does Fedora plan on shipping Linux-HA ( heartbeat )? Or is there a > replacement / similar package which is otherwise recommended ? Hi, The Linux-HA heartbeat package has just been submitted for review (and consequently inclusion) into Fedora Extras: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180897 If anyone would like to test/review this package on Fedora: http://www.soeterbroek.com/linux/fedora/extras/heartbeat/ Regards, Joost Soeterbroek fedora AT soeterbroek.com From mike at miketc.com Mon Feb 13 21:27:12 2006 From: mike at miketc.com (Mike Chambers) Date: Mon, 13 Feb 2006 15:27:12 -0600 Subject: GDM References: <1139857556.2578.3.camel@beast.rexursive.com><1139860070.2587.4.camel@halflap> <1139861771.16457.2.camel@intrepid> <1139865227.16457.7.camel@intrepid> Message-ID: <003301c630e4$412ef130$0301a8c0@miketc.com> ----- Original Message ----- From: "Thomas J. Baker" To: "Development discussions related to Fedora Core" Sent: Monday, February 13, 2006 3:13 PM Subject: Re: GDM > > It doesn't appear my problems are related to gdm. Even at runlevel 3, > startx bombs out too. The biggest suck is that there don't seem to be > any error messages anywhere... I am experiencing the same problem as you are, even in run level 3. If you try to run gdmsetup, I get an Gtk-Warning error. I hope that whoever fixes this one, would hopefully post a working copy of the rpm somewhere (people.redhat.com server would work) until it hits rawhide. Thanks, Mike Chambers Madisonville, KY From jon.nettleton at gmail.com Mon Feb 13 21:36:05 2006 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Mon, 13 Feb 2006 16:36:05 -0500 Subject: GDM In-Reply-To: <003301c630e4$412ef130$0301a8c0@miketc.com> References: <1139857556.2578.3.camel@beast.rexursive.com> <1139860070.2587.4.camel@halflap> <1139861771.16457.2.camel@intrepid> <1139865227.16457.7.camel@intrepid> <003301c630e4$412ef130$0301a8c0@miketc.com> Message-ID: On 2/13/06, Mike Chambers wrote: > > ----- Original Message ----- > From: "Thomas J. Baker" > To: "Development discussions related to Fedora Core" > > Sent: Monday, February 13, 2006 3:13 PM > Subject: Re: GDM > > > > > It doesn't appear my problems are related to gdm. Even at runlevel 3, > > startx bombs out too. The biggest suck is that there don't seem to be > > any error messages anywhere... > > I am experiencing the same problem as you are, even in run level 3. If > you > try to run gdmsetup, I get an Gtk-Warning error. I hope that whoever > fixes > this > one, would hopefully post a working copy of the rpm somewhere > (people.redhat.com server would work) until it hits rawhide. > > Thanks, > > Mike Chambers > Madisonville, KY > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list This problem appears to be two fold. I fixed /etc/gdm/custom.conf, but still could not log in to an X session. I had to move my .fonts directory to .fonts-bak and then gnome-session stopped crashing. I haven't had time to debug it, or file a bug yet. Maybe later tonight. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at erwinrol.com Mon Feb 13 21:37:32 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Mon, 13 Feb 2006 22:37:32 +0100 Subject: phpldapadmin crash/bug Message-ID: <1139866652.17385.120.camel@xpc.home.erwinrol.com> I have a problem with phpldapadmin, it crashes my httpd. After dumping core and gdb i get the attached backtrace. It seems to be the first access to a ldap connection, for example (striped from lost of comments) the following code (from lib/server_funtions.php) seems to cause the problem. $resource = @ldap_connect( $this->host ); @ldap_set_option( $resource, LDAP_OPT_PROTOCOL_VERSION, 3 ); @ldap_set_option( $resource, LDAP_OPT_REFERRALS, 0); The ldap_connect goes OK since resource is not null. But the first function that gets resource as a argument causes the sigsegv. Before i file a bug i would like to ask if someone reproduce the problem ? - Erwin #0 0x00002aaaab200826 in ldap_set_option () from /usr/lib64/libldap-2.3.so.0 #1 0x00002aaab2501e9b in zif_ldap_set_option (ht=Variable "ht" is not available. ) at /usr/src/debug/php-5.1.2/ext/ldap/ldap.c:1860 #2 0x00002aaab0628a5e in zend_do_fcall_common_helper_SPEC (execute_data=0x7fffffe427a0) at /usr/src/debug/php-5.1.2/Zend/zend_vm_execute.h:192 #3 0x00002aaab061a3cc in execute (op_array=0x5555559782f8) at /usr/src/debug/php-5.1.2/Zend/zend_vm_execute.h:92 #4 0x00002aaab06284ea in zend_do_fcall_common_helper_SPEC (execute_data=0x7fffffe443e0) at /usr/src/debug/php-5.1.2/Zend/zend_vm_execute.h:226 #5 0x00002aaab061a3cc in execute (op_array=0x55555592f7d8) at /usr/src/debug/php-5.1.2/Zend/zend_vm_execute.h:92 #6 0x00002aaab05fd79e in zend_execute_scripts (type=8, retval=Variable "retval" is not available. ) at /usr/src/debug/php-5.1.2/Zend/zend.c:1101 #7 0x00002aaab05c2c46 in php_execute_script (primary_file=0x7fffffe46980) at /usr/src/debug/php-5.1.2/main/main.c:1720 #8 0x00002aaab067a604 in php_handler (r=0x555555923538) at /usr/src/debug/php-5.1.2/sapi/apache2handler/sapi_apache2.c:584 #9 0x000055555557df5a in ap_run_handler (r=0x555555923538) at /usr/src/debug/httpd-2.2.0/server/config.c:157 #10 0x00005555555813b2 in ap_invoke_handler (r=0x555555923538) at /usr/src/debug/httpd-2.2.0/server/config.c:371 #11 0x000055555558bc28 in ap_process_request (r=0x555555923538) at /usr/src/debug/httpd-2.2.0/modules/http/http_request.c:258 #12 0x0000555555588ec0 in ap_process_http_connection (c=0x555555919358) at /usr/src/debug/httpd-2.2.0/modules/http/http_core.c:171 #13 0x0000555555585192 in ap_run_process_connection (c=0x555555919358) at /usr/src/debug/httpd-2.2.0/server/connection.c:43 #14 0x000055555558f5fb in child_main (child_num_arg=Variable "child_num_arg" is not available. ) at /usr/src/debug/httpd-2.2.0/server/mpm/prefork/prefork.c:640 #15 0x000055555558f88a in make_child (s=0x5555556b2de8, slot=4) at /usr/src/debug/httpd-2.2.0/server/mpm/prefork/prefork.c:736 #16 0x000055555558f940 in startup_children (number_to_start=4) at /usr/src/debug/httpd-2.2.0/server/mpm/prefork/prefork.c:754 #17 0x0000555555590636 in ap_mpm_run (_pconf=Variable "_pconf" is not available. ) at /usr/src/debug/httpd-2.2.0/server/mpm/prefork/prefork.c:975 #18 0x000055555556b59c in main (argc=1, argv=0x7fffffe46f68) at /usr/src/debug/httpd-2.2.0/server/main.c:712 From sdl.web at gmail.com Mon Feb 13 21:48:42 2006 From: sdl.web at gmail.com (leon) Date: Mon, 13 Feb 2006 21:48:42 +0000 Subject: two version of the same apps installed, bug? References: <20060213195240.80489.qmail@web51514.mail.yahoo.com> Message-ID: Steve G writes: | >Is it this a bug or a new feature of yum? | | This can happen for a variety of reasons. For example, SE linux can cause | problems if you are using rawhide; yum may have had a bug on one day that didn't | let it clean up, etc. I posted a shell script last week that finds this problem | and another one if you are on a multilib platform. You can find it here: | | https://www.redhat.com/archives/fedora-test-list/2006-February/msg00430.html | | | -Steve Thanks. That fixes the problem. -- Leon From sdl.web at gmail.com Mon Feb 13 21:52:39 2006 From: sdl.web at gmail.com (leon) Date: Mon, 13 Feb 2006 21:52:39 +0000 Subject: gnome-power-manager quits unexpectedly References: <4b3752c70602122012n73a21d1bic65b6c926247f8db@mail.gmail.com> <15e53e180602130204r3ad5c492i@mail.gmail.com> <43F0EE07.1070501@stasis.org> Message-ID: Rowan Kerr writes: | Richard Hughes wrote: | > On 13/02/06, S Baig wrote: | >> ** ERROR **: This program cannot start until you start the dbus session | >> daemon | >> This is usually started in X or gnome startup (depending on distro) | >> You can launch the session dbus-daemon manually with this command: | >> eval `dbus-launch --auto-syntax` | >> | >> | >> I cannot find 'dbus-launch' anywhere in my path, but I verified using | >> 'system-config-services' that the messagebus service is running. Has anyone | >> else had this problem? | > Do you have dbus-x11 installed? | | I get the same problem persistently since installing from fc5t2 and | upgrading to rawhide. (I just did another update this morning). | | dbus-x11 is: dbux-x11-0.60-7.2 and messagebus is set to run on startup. | | I get another message about selinux: | ** (gnome-power-manager:2347):WARNING **: main: an SELinux policy | prevents this sender from sending this message... (rejected message | had interface "org.freedesktop.DBus" member "Hello" error name | "(unset") destination "org.freedeesktop.DBus") | | Is there somewhere I should be resetting my selinux config or | what.. This bug has been hanging around for a while. My laptop can't do suspend/hibernate. Hope it get fixed when test3 released. -- Leon From bojan at rexursive.com Mon Feb 13 22:13:19 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 14 Feb 2006 09:13:19 +1100 Subject: GDM In-Reply-To: <1139860070.2587.4.camel@halflap> References: <1139857556.2578.3.camel@beast.rexursive.com> <1139860070.2587.4.camel@halflap> Message-ID: <20060214091319.53up4zme808808cw@imp.rexursive.com> Quoting Ray Strode : > Hi, >> Is it just my box or did others see breakage of GDM with the latest >> jumbo update? For whatever reason, it wants to start a "Failsafe GNOME >> session" now (it claims that it cannot find or run the base session >> script). I'm also getting gdmsetup do "double free or corruption"... > This should be fixed in tomorrow's rawhide. In the mean time, > > sed -i -e 's@/etc/X11/gdm@/etc/gdm at g' /etc/gdm/custom.conf > > should fix things up Thanks. That does the trick with GDM, but gdm is still crashing (occasionally). Bug opened: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181425 -- Bojan From shezanbaig2004 at gmail.com Mon Feb 13 23:54:54 2006 From: shezanbaig2004 at gmail.com (S Baig) Date: Mon, 13 Feb 2006 18:54:54 -0500 Subject: gnome-power-manager quits unexpectedly In-Reply-To: <15e53e180602130204r3ad5c492i@mail.gmail.com> References: <4b3752c70602122012n73a21d1bic65b6c926247f8db@mail.gmail.com> <15e53e180602130204r3ad5c492i@mail.gmail.com> Message-ID: <4b3752c70602131554s2bf870bas9c04ce619a2075dc@mail.gmail.com> On 2/13/06, Richard Hughes wrote: > > Do you have dbus-x11 installed? Thanks Richard! I installed dbus-x11 and that solved the problem. -shez- -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at knox.net.nz Tue Feb 14 00:35:11 2006 From: michael at knox.net.nz (Michael J Knox) Date: Tue, 14 Feb 2006 13:35:11 +1300 Subject: snort inline on Fedora In-Reply-To: <20060213143530.GD5657@angus.ind.WPI.EDU> References: <1139796228.25720.9.camel@cosima.et.endace.com> <20060213143530.GD5657@angus.ind.WPI.EDU> Message-ID: <1139877312.15916.7.camel@cosima.et.endace.com> On Mon, 2006-02-13 at 09:35 -0500, Chuck Anderson wrote: > On Mon, Feb 13, 2006 at 03:03:48PM +1300, Michael J Knox wrote: > > The suggestion is to point to a set of "real" kernel includes instead of > > RH's glibc-kernheaders package. > > Kernel includes should never be used from userspace. > > > Has anyone got some suggestions on what should be done about this or how > > to work around it (from a packaging standpoint) ? > > If the glibc-kernheaders are insufficient, and snort is sticking to > documented public interfaces, then glibc-kernheaders should be fixed > to define those interfaces. > Ok, so do I go back to snort and find out whats what or does RH update glibc-kernheaders? Michael From fcd-cornette at insight.rr.com Tue Feb 14 03:22:56 2006 From: fcd-cornette at insight.rr.com (Jim Cornette) Date: Mon, 13 Feb 2006 22:22:56 -0500 Subject: gnome-power-manager quits unexpectedly In-Reply-To: <4b3752c70602122012n73a21d1bic65b6c926247f8db@mail.gmail.com> References: <4b3752c70602122012n73a21d1bic65b6c926247f8db@mail.gmail.com> Message-ID: <43F14D10.1080500@insight.rr.com> S Baig wrote: > Hi, > > I just installed Fedora5 Test2 and when I log into Gnome, I immediately > get a message box saying "The Application "gnome-power-manager" has quit > unexpectedly". Then I open a terminal and try running > 'gnome-power-manager' from the command prompt, I get the same message > box, but also the following text is printed on the terminal: > > ** (gnome-power-manager:6362): WARNING **: main: Unable to determine the > address of the message bus > > ** ERROR **: This program cannot start until you start the dbus session > daemon > This is usually started in X or gnome startup (depending on distro) > You can launch the session dbus-daemon manually with this command: > eval `dbus-launch --auto-syntax` > > > I cannot find 'dbus-launch' anywhere in my path, but I verified using > 'system-config-services' that the messagebus service is running. Has > anyone else had this problem? > > Thanks, > -shez- > The problem is on the FC5T2 disc(s) - If you apply updates, it shoud go away and work normally. Yes, I had the problem. Check the archives for the fedora-test list. There were many discussions related to gnome-power-manager in the later days of FC5T1 and the release of FC5T2. Jim -- Today you'll start getting heavy metal radio on your dentures. From seandarcy2 at gmail.com Tue Feb 14 03:40:23 2006 From: seandarcy2 at gmail.com (sean) Date: Mon, 13 Feb 2006 22:40:23 -0500 Subject: can anybody install gnome-volume-manager? Message-ID: on amd64: rpm -Uvh gnome-volume-manager-1.5.11-1.2.x86_64.rpm Preparing... ########################################### [100%] 1:gnome-volume-manager ########################################### [100%] error: unpacking of archive failed on file /usr/bin/magicdev: cpio: rename failed - Operation not permitted I've also rebuilt from the src.rpm. Same result. Looked at the spec file. Nothing odd. Am I missing some magic handshake? sean From naoki at valuecommerce.com Tue Feb 14 06:49:59 2006 From: naoki at valuecommerce.com (Naoki) Date: Tue, 14 Feb 2006 15:49:59 +0900 Subject: rawhide report: 20060213 changes 2/2 In-Reply-To: <5256d0b0602130409l1424c059u9587041118ee4189@mail.gmail.com> References: <200602130748.k1D7mQKs019059@porkchop.devel.redhat.com> <5256d0b0602130409l1424c059u9587041118ee4189@mail.gmail.com> Message-ID: <43F17D97.1020709@valuecommerce.com> Peter Robinson wrote: >> OK, do I dare? >> >> Has anyone tried this massive update? Any good/bad reports? >> No worries at all here. From pjones at redhat.com Tue Feb 14 07:08:41 2006 From: pjones at redhat.com (Peter Jones) Date: Tue, 14 Feb 2006 02:08:41 -0500 Subject: rawhide report: 20060209 changes (part 1/2) In-Reply-To: <5256d0b0602090747o1dbd9081yfca2befab7c745c7@mail.gmail.com> References: <200602091507.k19F7p2g012345@porkchop.devel.redhat.com> <5256d0b0602090728i7c4a879bta5a8098bc3724199@mail.gmail.com> <1139499878.7727.0.camel@orodruin.boston.redhat.com> <5256d0b0602090747o1dbd9081yfca2befab7c745c7@mail.gmail.com> Message-ID: <1139900922.10271.5.camel@localhost.localdomain> On Thu, 2006-02-09 at 15:47 +0000, Peter Robinson wrote: > > > Is there any reason why its still shipped or is it just an oversight? > > > While I don't have quite everything installed nothing depends on it > > > and hence I've removed it on my install without issues. > > > > Still required by gnucash > > So that would explain why I don't have a need for it then :-) FWIW, "repoquery" can answer this sort of question for you. -- Peter From gnomeuser at gmail.com Tue Feb 14 07:22:32 2006 From: gnomeuser at gmail.com (David Nielsen) Date: Tue, 14 Feb 2006 08:22:32 +0100 Subject: rawhide report: 20060213 changes 2/2 In-Reply-To: <43F17D97.1020709@valuecommerce.com> References: <200602130748.k1D7mQKs019059@porkchop.devel.redhat.com> <5256d0b0602130409l1424c059u9587041118ee4189@mail.gmail.com> <43F17D97.1020709@valuecommerce.com> Message-ID: <1139901752.2242.1.camel@price.stavtrup-st.dk> tir, 14 02 2006 kl. 15:49 +0900, skrev Naoki: > Peter Robinson wrote: > >> OK, do I dare? > >> > >> Has anyone tried this massive update? Any good/bad reports? > >> > No worries at all here. when connected to imps2 my trackball lags like crazy - it's quite trippy, when connected to usb it's just fine. - David -- Obligatory shameless blog plug - the GNOME commentary located at: www.lovesunix.net/blog From paul at city-fan.org Tue Feb 14 07:39:47 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 14 Feb 2006 07:39:47 +0000 Subject: can anybody install gnome-volume-manager? In-Reply-To: References: Message-ID: <1139902787.28615.15.camel@laurel.intra.city-fan.org> On Mon, 2006-02-13 at 22:40 -0500, sean wrote: > on amd64: > > rpm -Uvh gnome-volume-manager-1.5.11-1.2.x86_64.rpm > Preparing... > ########################################### [100%] > 1:gnome-volume-manager > ########################################### [100%] > error: unpacking of archive failed on file > /usr/bin/magicdev: cpio: rename failed - Operation not permitted > > I've also rebuilt from the src.rpm. Same result. Looked at > the spec file. Nothing odd. > > Am I missing some magic handshake? What's /usr/bin/magicdev on your system? $ ls -l /usr/bin/magicdev And what is it in the rpm? $ rpm -qlpv gnome-volume-manager-1.5.11-1.2.x86_64.rpm | grep -F /usr/bin/magicdev Paul. From buildsys at redhat.com Tue Feb 14 08:39:43 2006 From: buildsys at redhat.com (Build System) Date: Tue, 14 Feb 2006 03:39:43 -0500 Subject: rawhide report: 20060214 changes Message-ID: <200602140839.k1E8dgJl007784@porkchop.devel.redhat.com> Removed package kernel-xen Updated Packages: GConf-1.0.9-18.2.1 ------------------ * Mon Feb 13 2006 Jesse Keating - 1.0.9-18.2.1 - rebump for build order issues during double-long bump * Fri Feb 10 2006 Jesse Keating - 1.0.9-18.2 - bump again for double-long bug on ppc(64) GConf2-2.13.5-3.2.1 ------------------- * Mon Feb 13 2006 Jesse Keating - 2.13.5-3.2.1 - rebump for build order issues during double-long bump * Fri Feb 10 2006 Jesse Keating - 2.13.5-3.2 - bump again for double-long bug on ppc(64) GFS-6.1.5-0.FC5.1 ----------------- * Tue Feb 07 2006 Jesse Keating - 6.1.4-0.FC5.1.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 16 2005 Chris Feist - Rebuilt w/ new upstream sources * Fri Dec 09 2005 Jesse Keating - rebuilt GFS-kernel-2.6.15-4 ------------------- * Tue Feb 07 2006 Jesse Keating - 2.6.15.0-20051219.162641.FC5.10.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Jan 13 2006 Chris Feist - Rebuilt and bumped version number to 2.6.15 Guppi-0.40.3-24.2.1.1 --------------------- * Mon Feb 13 2006 Bill Nottingham - 0.40.3-24.2.1.1 - again and again and again and again and again * Fri Feb 10 2006 Jesse Keating - 0.40.3-24.2.1 - bump again for double-long bug on ppc(64) HelixPlayer-1:1.0.6-1.2.2 ------------------------- * Mon Feb 13 2006 Jesse Keating - 1:1.0.6-1.2.2 - rebump for build order issues during double-long bump * Fri Feb 10 2006 Jesse Keating - 1:1.0.6-1.2.1 - bump again for double-long bug on ppc(64) ImageMagick-6.2.5.4-4.2.1 ------------------------- * Mon Feb 13 2006 Jesse Keating - 6.2.5.4-4.2.1 - rebump for build order issues during double-long bump * Fri Feb 10 2006 Jesse Keating - 6.2.5.4-4.2 - bump again for double-long bug on ppc(64) MAKEDEV-3.21-3 -------------- * Mon Feb 13 2006 Nalin Dahyabhai 3.21-3 - rebuild MySQL-python-1.2.0-3.2.2 ------------------------ * Mon Feb 13 2006 Jesse Keating - 1.2.0-3.2.2 - rebump for build order issues during double-long bump * Fri Feb 10 2006 Jesse Keating - 1.2.0-3.2.1 - bump again for double-long bug on ppc(64) NetworkManager-0.5.1-12.cvs20060213 ----------------------------------- * Mon Feb 13 2006 Dan Williams 0.5.1-12.cvs20060213 - Minor bug fixes - Update to VPN dbus API for passing user-defined routes to vpn service ORBit-1:0.5.17-15.2.2 --------------------- * Mon Feb 13 2006 Jesse Keating - 1:0.5.17-15.2.2 - rebump for build order issues during double-long bump * Fri Feb 10 2006 Jesse Keating - 1:0.5.17-15.2.1 - bump again for double-long bug on ppc(64) ORBit2-2.13.3-1.2 ----------------- * Mon Feb 13 2006 Jesse Keating - 2.13.3-1.2 - rebump for build order issues during double-long bump * Fri Feb 10 2006 Jesse Keating - 2.13.3-1.1 - bump again for double-long bug on ppc(64) OpenIPMI-1.4.14-18.2.1 ---------------------- * Mon Feb 13 2006 Jesse Keating - 1.4.14-18.2.1 - rebump for build order issues during double-long bump * Fri Feb 10 2006 Jesse Keating - 1.4.14-18.2 - bump again for double-long bug on ppc(64) PyQt-3.15-1.2.2 --------------- * Mon Feb 13 2006 Jesse Keating - 3.15-1.2.2 - rebump for build order issues during double-long bump * Fri Feb 10 2006 Jesse Keating - 3.15-1.2.1 - bump again for double-long bug on ppc(64) PyXML-0.8.4-3.2.2 ----------------- * Mon Feb 13 2006 Jesse Keating - 0.8.4-3.2.2 - rebump for build order issues during double-long bump * Fri Feb 10 2006 Jesse Keating - 0.8.4-3.2.1 - bump again for double-long bug on ppc(64) SDL-1.2.9-5.2.1 --------------- * Mon Feb 13 2006 Jesse Keating - 1.2.9-5.2.1 - rebump for build order issues during double-long bump * Fri Feb 10 2006 Jesse Keating - 1.2.9-5.2 - bump again for double-long bug on ppc(64) SysVinit-2.86-2.2.2 ------------------- * Mon Feb 13 2006 Bill Nottingham - 2.86-2.2.2 - and again... * Fri Feb 10 2006 Jesse Keating - 2.86-2.2 - bump again for double-long bug on ppc(64) Xaw3d-1.5E-6.2.2 ---------------- * Mon Feb 13 2006 Jesse Keating - 1.5E-6.2.2 - rebump for build order issues during double-long bump * Fri Feb 10 2006 Jesse Keating - 1.5E-6.2.1 - bump again for double-long bug on ppc(64) agg-2.3-3 --------- * Mon Feb 13 2006 Caolan McNamara - 2.3-3 - BuildRequires anaconda-10.92.4-1 ------------------ * Tue Feb 14 2006 Jeremy Katz - 10.92.4-1 - improve globbing for xen guest kernels - Don't add a kernel if one is already selected. * Mon Feb 13 2006 Jeremy Katz - 10.92.3-1 - Don't debug log about missing help text (clumens) - Reduce deps for pkgorder - Updated kickstart docs (clumens) * Mon Feb 13 2006 Jeremy Katz - 10.92.2-1 - more x86_64 xen guest fixing beagle-0.2.1-5 -------------- * Mon Feb 13 2006 Ray Strode - 0.2.1-4 - remove preferences from accessories menu - hide holmes (gnome-panel shows it in places now) - change holmes icon to one we have * Sun Feb 12 2006 Christopher Aillon - 0.2.1-4 - Update sqlite3.patch so that it behaves better with sqlite2 and 3 ccs-1.0.3-0.2 ------------- checkpolicy-1.29.2-1 -------------------- * Mon Feb 13 2006 Dan Walsh - 1.29.2-1 - Latest upgrade from NSA * Merged optionals in base patch from Joshua Brindle. * Mon Feb 13 2006 Dan Walsh - 1.29.1-1.2 - Need to build againi chkconfig-1.3.27-1 ------------------ * Mon Feb 13 2006 Bill Nottingham 1.3.27-1 - translation updates * Thu Feb 02 2006 Bill Nottingham 1.3.26-1 - add support for resetting priorities without on/off status (#178864) * Wed Nov 30 2005 Bill Nottingham 1.3.25-1 - return an error if changing services fails (#150235) cman-kernel-2.6.15.0-20051219.162641.FC5.11.4 --------------------------------------------- * Tue Feb 07 2006 Jesse Keating - 2.6.15.0-20051219.162641.FC5.11.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Jan 13 2006 Chris Feist - Rebuilt and bumped version number to 2.6.15 compat-gcc-296-2.96-135 ----------------------- * Mon Feb 13 2006 Jakub Jelinek 2.96-135 - replace -mtune=generic in $RPM_OPT_FLAGS with something that GCC 2.96-RH groks compat-gcc-32-3.2.3-55.fc5 -------------------------- * Sat Feb 11 2006 Jakub Jelinek 3.2.3-55.fc5 - replace -mtune=generic in $RPM_OPT_FLAGS with something that GCC 3.2.3 groks devhelp-0.11-2 -------------- * Sun Feb 12 2006 Christopher Aillon - 0.11-2 - Rebuild * Tue Feb 07 2006 Jesse Keating - 0.11-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes dlm-kernel-2.6.15.0-20051219.162641.FC5.9.3 ------------------------------------------- * Tue Feb 07 2006 Jesse Keating - 2.6.15.0-20051219.162641.FC5.9.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Jan 13 2006 Chris Feist - Rebuilt and bumped version number to 2.6.15 eel2-2.13.91-1 -------------- * Mon Feb 13 2006 Matthias Clasen - 2.13.91-1 - Update to 2.13.91 ekiga-1.99.1-1 -------------- * Mon Feb 13 2006 Daniel Veillard - 1.99.1-1 - new beta release issued eog-2.13.90-2 ------------- * Mon Feb 13 2006 Matthias Clasen - 2.13.90-2 - Append NoDisplay=true to the right file epiphany-1.9.6-3.1 ------------------ * Mon Feb 13 2006 Jesse Keating - 1.9.6-3.1 - rebump for build order issues during double-long bump evolution-connector-2.5.9.0-2.2.1 --------------------------------- * Mon Feb 13 2006 Jesse Keating - 2.5.9.0-2.2.1 - rebump for build order issues during double-long bump f-spot-0.1.8-3 -------------- * Sun Feb 12 2006 Christopher Aillon - 0.1.8-3 - Rebuild fence-1.32.17-0.FC5.1 --------------------- gcc-4.1.0-0.25 -------------- * Mon Feb 13 2006 Jakub Jelinek 4.1.0-0.25 - update from gcc-4_1-branch (-r110831:110903) - PRs c++/16405, c++/24996, fortran/14771, fortran/20858, fortran/25756, middle-end/22439 - merge gomp changes from trunk (-r110719:110720, -r110852:110853 and -r110907:110908) - PR libgomp/25936 - fix gimplification of const fn pointers to builting functions (PR middle-end/26092) - make sure Fortran length artifical variables aren't SAVEd (Andrew Pinski, PR fortran/26246) gdm-1:2.13.0.8-1 ---------------- * Mon Feb 13 2006 Ray Strode - 1:2.13.0.8-1 - update to 2.13.0.8 * Mon Feb 13 2006 Ray Strode - 1:2.13.0.7.0.2006.02.12-2 - migrate custom.conf settings with /etc/X11/gdm to /etc/gdm gecko-sharp2-0.11-5 ------------------- * Sun Feb 12 2006 Christopher Aillon 0.11-5 - Rebuild * Tue Feb 07 2006 Jesse Keating 0.11-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Tue Jan 31 2006 Christopher Aillon 0.11-4 - Rebuild glibc-2.3.90-37 --------------- * Mon Feb 13 2006 Jakub Jelinek 2.3.90-37 - update from CVS - *at fixes - unshare syscall wrapper gmime-2.1.19-3 -------------- * Sun Feb 12 2006 Christopher Aillon - 2.1.19-3 - Rebuild gnbd-kernel-2.6.15-3 -------------------- * Tue Feb 07 2006 Jesse Keating - 2.6.15.0-20051108.134753.FC5.18.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Jan 13 2006 Chris Feist - Rebuilt, bumped version number to 2.6.15 and added xen build. gnome-desktop-2.13.91-1 ----------------------- * Mon Feb 13 2006 Matthias Clasen - 2.13.91-1 - Update to 2.13.91 gnome-games-1:2.13.7-1 ---------------------- * Mon Feb 13 2006 Matthias Clasen - 2.13.7-1 - Update to 2.13.7 gnome-keyring-0.4.7-1 --------------------- * Mon Feb 13 2006 Matthias Clasen - 0.4.7-1 - Update to 0.4.7 gnome-libs-1:1.4.1.2.90-48.3 ---------------------------- * Mon Feb 13 2006 Jesse Keating - 1:1.4.1.2.90-48.3 - need to rebuild a 3rd time for long-double fixes. gnome-mount-0.4-0.cvs20060213.1 ------------------------------- * Mon Feb 13 2006 David Zeuthen - 0.4-0.cvs20060213.1 - fix build * Mon Feb 13 2006 David Zeuthen - 0.4-0.cvs20060213 - new upstream snapshot gnome-panel-2.13.90-3 --------------------- * Mon Feb 13 2006 Ray Strode - 2.13.90-3 - use beagle if available for search tool * Sun Feb 12 2006 Ray Strode - 2.13.90-2 - add first pass at gnome power manager integration gnome-power-manager-2.13.5.0.20060207-2 --------------------------------------- * Mon Feb 13 2006 Ray Strode - 2.13.5.0.20060207-2 - remove Hibernate and Suspend from menus as part of panel/g-p-m integration effort gnome-screensaver-2.13.90-4 --------------------------- * Mon Feb 13 2006 Ray Strode - 2.13.90-4 - migrate xscreensaver screensavers in %post as well as the triggers already there (bug 180984) gnome-session-2.13.91-1 ----------------------- * Mon Feb 13 2006 Matthias Clasen - 2.13.91-1 - Update to 2.13.91 gnome-vfs2-2.13.91-1 -------------------- * Mon Feb 13 2006 Matthias Clasen - 2.13.91-1 - Update to 2.13.91 gnome-volume-manager-1.5.11-2 ----------------------------- * Mon Feb 13 2006 Ray Strode - 1.5.11-2 - get rid of gnome-printer-add gnopernicus-1.0.2-1 ------------------- * Mon Feb 13 2006 Matthias Clasen - 1.0.2-1 - Update to 1.0.2 gnutls-1.2.10-1 --------------- * Mon Feb 13 2006 Tomas Mraz - 1.2.10-1 - updated to new version (fixes CVE-2006-0645) gpm-1.20.1-73.3 --------------- * Mon Feb 13 2006 Petr Rockai - 1.20.1-73.3 - rebuild due to failure on x86-64 (possibly a glitch?) * Fri Feb 10 2006 Jesse Keating - 1.20.1-73.2 - bump again for double-long bug on ppc(64) grub-0.97-3 ----------- * Mon Feb 13 2006 Peter Jones - 0.97-3 - fix partition names on dmraid gstreamer-0.10.3-2 ------------------ * Mon Feb 13 2006 Christopher Aillon - 0.10.3-2 - Rebuild * Fri Feb 10 2006 Christopher Aillon - 0.10.3-1 - Update to 0.10.3 * Tue Feb 07 2006 Jesse Keating - 0.10.2-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes gtk-sharp-1.0.10-5 ------------------ * Sun Feb 12 2006 Christopher Aillon 1.0.10-5 - Rebuild * Tue Feb 07 2006 Jesse Keating 1.0.10-4.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Thu Jan 19 2006 Alexander Larsson 1.0.10-4 - mono now builds on s390x gtkhtml3-3.9.91-1 ----------------- * Mon Feb 13 2006 Matthias Clasen - 3.9.91-1 - Update to 3.9.91 gulm-1.0.6-0.FC5.1 ------------------ hal-0.5.7-0.cvs20060213.1 ------------------------- * Mon Feb 13 2006 David Zeuthen - 0.5.7-0.cvs20060213.1 - fix build * Mon Feb 13 2006 David Zeuthen - 0.5.7-0.cvs20060213 - Upstream CVS snapshot. Drop a patch that is upstream. Switch to using udev rules instead of hotplug helpers for udev->hald channel. hwbrowser-0.26-1 ---------------- * Mon Feb 13 2006 Nils Philippsen 0.26 - avoid traceback on startup (#177197), mark "None or built-in" string as translatable (patch by Frank Arnold) initscripts-8.28-1 ------------------ * Mon Feb 13 2006 Bill Nottingham 8.28-1 - kill nash-hotplug before starting udev () - silence warnings on /dev/pts remount () - more translation updates * Mon Feb 13 2006 Bill Nottingham 8.27-1 - translation updates - lang.sh: revert fix for #176832, it's broken - ifup-aliases fixes (,) * Tue Feb 07 2006 Bill Nottingham 8.26-1 - revert "rc.sysinit: don't mount usbfs, libusb no longer uses it" change - add some ugly hacks to make sure net hotplug doesn't run after unclean shutdown (#177795) - don't mount /sys and /proc in rc.sysinit - the initrd already does () - halt: try to unmount tmpfs filesystems before swapoff (#174000, ) kernel-2.6.15-1.1948_FC5 ------------------------ * Mon Feb 13 2006 Rik van Riel - go with the SMP workaround from Hubertus * Mon Feb 13 2006 Dave Jones - 2.6.16rc3-git1 - Merge kernel-xen back to kernel. * Mon Feb 13 2006 Juan Quintela - rebase rawhide 1.1941. krb5-auth-dialog-0.6.cvs20060212-1 ---------------------------------- * Sun Feb 12 2006 Christopher Aillon - 0.6.cvs20060212-1 - Update to latest CVS to get some of Nalin's fixes kudzu-1.2.28-1 -------------- * Mon Feb 13 2006 Bill Nottingham - 1.2.28-1 - vbe/edid probing on x86_64 via x86emu - thanks to Matthew Garrett & Tollef Fog Heen * Mon Feb 13 2006 Bill Nottingham - 1.2.27-1 - restrict video devices to PCI class 0300, correctly (should solve #176978) * Mon Feb 13 2006 Bill Nottingham - 1.2.26-1 - restrict video devices to PCI class 0300 (should solve #176978) - translation updates lcms-1.15-1.2.1 --------------- * Mon Feb 13 2006 Jesse Keating - 1.15-1.2.1 - rebump for build order issues during double-long bump libdv-0:0.103-4.3 ----------------- * Mon Feb 13 2006 Paul Nasrat - 0:0.103-4.3 - Patch to build with gcc 4.1 * Fri Feb 10 2006 Jesse Keating - 0:0.103-4.2.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 0:0.103-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes libsemanage-1.5.23-1 -------------------- * Mon Feb 13 2006 Dan Walsh - 1.5.23-1 - Upgrade to latest from NSA * Merged optionals in base patch from Joshua Brindle. * Merged treat seusers/users_extra as optional sections patch from Ivan Gyurdiev. * Merged parse_optional fixes from Ivan Gyurdiev. libsepol-1.11.14-2 ------------------ * Mon Feb 13 2006 Dan Walsh 1.11.14-2 - Fix post install not to fire if /dev/initctr does not exist * Mon Feb 13 2006 Dan Walsh 1.11.14-1 - Upgrade to latest from NSA * Merged optionals in base patch from Joshua Brindle. libuser-0.54.4-1 ---------------- * Mon Feb 13 2006 Miloslav Trmac - 0.54.4-1 - New release with updated translations libwnck-2.13.91-1 ----------------- * Mon Feb 13 2006 Matthias Clasen - 2.13.91-1 - Update to 2.13.91 m17n-db-1.3.2-2 --------------- * Tue Feb 14 2006 Jens Petersen - 1.3.2-2 - add Indian input maps ported from scim-tables - add Nepali subpackage magma-1.0.4-0.1 --------------- * Fri Feb 10 2006 Jesse Keating - 1.0.3-3.2.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 1.0.3-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 09 2005 Jesse Keating - rebuilt mailcap-2.1.20-1 ---------------- * Mon Feb 13 2006 Miroslav Lichvar 2.1.20-1 - add OpenOffice.org 2.0 mime types (#173789) metacity-2.13.89-1 ------------------ * Mon Feb 13 2006 Matthias Clasen - 2.13.89-1 - Update to 2.13.89 mkinitrd-5.0.23-1 ----------------- * Mon Feb 13 2006 Peter Jones - 5.0.23-1 - add basic hotplug handler and firmware loader * Mon Feb 13 2006 Jesse Keating - 5.0.22-1.1 - rebump for build order issues during double-long bump * Sat Feb 11 2006 Peter Jones - 5.0.22-1 - formatting cleanups - prefix partition number with "p" for partitions on dmraid - add support for disabling partitions which overlap with partitions on dm devices. - add multipath support - fix dm creation ordering and partition detection - add "network" command (katzj) - add nfsroot support (katzj) - add iscsi support (katzj) - put "showlabels" back into nash mod_python-3.1.4-4 ------------------ * Mon Feb 13 2006 Joe Orton 3.1.4-4 - fix configure syntax error with bash 3.1 (#180731) * Fri Feb 10 2006 Jesse Keating - 3.1.4-3.2.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 3.1.4-3.2 - rebuilt for new gcc4.1 snapshot and glibc changes module-init-tools-3.2-0.pre9.2.2.1 ---------------------------------- * Mon Feb 13 2006 Jesse Keating - 3.2-0.pre9.2.2.1 - rebump for build order issues during double-long bump nautilus-2.13.91-1 ------------------ * Mon Feb 13 2006 Matthias Clasen - 2.13.91-1 - Update to 2.13.91 nss_ldap-248-2.2 ---------------- * Mon Feb 13 2006 Jesse Keating - 248-2.2 - rebump for build order issues during double-long bump oaf-0.6.10-12.3 --------------- * Mon Feb 13 2006 Jesse Keating - 0.6.10-12.3 - needed to build a 3rd from for the long-double issues * Mon Feb 13 2006 Jesse Keating - 0.6.10-12.2.2 - rebump for build order issues during double-long bump opal-2.1.3-1 ------------ * Mon Feb 13 2006 Daniel Veillard - 2.1.3-1 - new beta version for ekiga openldap-2.3.19-4 ----------------- * Mon Feb 13 2006 Jay Fenlason 2.3.19-4 - Re-fix ldap.init openssh-4.3p2-1 --------------- * Mon Feb 13 2006 Tomas Mraz - 4.3p2-1 - new version pam_krb5-2.2.6-2 ---------------- * Mon Feb 13 2006 Nalin Dahyabhai - 2.2.6-2 - rebuild perl-4:5.8.8-3 -------------- * Mon Feb 13 2006 Jason Vas Dias - 4:5.8.8-3 - Apply upstream bugfix patch 27170 * Fri Feb 10 2006 Jesse Keating - 4:5.8.8-2.1 - bump again for double-long bug on ppc(64) * Fri Feb 10 2006 Jason Vas Dias - 4:5.8.8-2 - Rebuild again - Debian released 5.8.8 patches today; apply only relevant difference: 03_fix_net_nntp : fix precedence in Net::NNTP::article from Brendan O'Dea policycoreutils-1.29.23-1 ------------------------- * Mon Feb 13 2006 Dan Walsh 1.29.23-1 - Update from upstream * Merged newrole -V/--version support from Glauber de Oliveira Costa. * Merged genhomedircon prefix patch from Dan Walsh. * Merged optionals in base patch from Joshua Brindle. portmap-4.0-65.2.2 ------------------ * Mon Feb 13 2006 Jesse Keating - 4.0-65.2.2 - rebump for build order issues during double-long bump postgresql-8.1.3-1 ------------------ * Mon Feb 13 2006 Tom Lane 8.1.3-1 - Update to PostgreSQL 8.1.3 (fixes bug #180617, CVE-2006-0553) - Update to jdbc driver build 405 - Modify multilib header hack to not break non-RH arches, per bug #177564 prelink-0.3.6-3 --------------- * Mon Feb 13 2006 Jakub Jelinek 0.3.6-3 - rebuilt again, disable -Wl,-z,nocopyreloc tests on x86_64, nocopyreloc really doesn't work on this platform (#180552) pump-0.8.24-1.2.2 ----------------- * Mon Feb 13 2006 Jesse Keating - 0.8.24-1.2.2 - rebump for build order issues during double-long bump pwlib-1.9.3-1 ------------- * Mon Feb 13 2006 Daniel Veillard - 1.9.3-1 - new beta version for ekiga pykickstart-0.20-1 ------------------ * Mon Feb 13 2006 Chris Lumens 0.20-1 - Correctly set --noformat and --useexisting on lvm and raid. * Mon Feb 13 2006 Chris Lumens 0.19-1 - --onboot requires a value (#180987). - Be more strict about commands that don't take arguments. python-pyblock-0.14-1 --------------------- * Mon Feb 13 2006 Peter Jones - 0.14-1 - remove member partitions when we activate, rebuild them when we deactivate - add another "count_devices(ctx->lc, NATIVE)" in discover_raiddevs. it seems to help... rgmanager-1.9.34-5 ------------------ * Thu May 05 2005 Chris Feist - Cleaned up .spec file. * Thu May 05 2005 Chris Feist - Added patch to disable starting up the init scripts. * Mon Dec 20 2004 Chris Feist - Rebuild with new sources. rgmanager-1.9.46-0.FC5.0 ------------------------ rhgb-0.16.2-21.2.1 ------------------ * Mon Feb 13 2006 Jesse Keating - 0.16.2-21.2.1 - rebump for build order issues during double-long bump rng-utils-1:2.0-1.11 -------------------- * Mon Feb 13 2006 Dave Jones - rebuild. samba-0:3.0.21b-2 ----------------- * Mon Feb 13 2006 Jay Fenlason 3.0.21b-2 - New upstream version. - Since the rawhide kernel has dropped support for smbfs, remove smbmount and smbumount. Users should use mount.cifs instead. - Upgrade to 3.0.21b scim-pinyin-0.5.91-4.3 ---------------------- * Mon Feb 13 2006 Qian Shen - 0.5.91-4.3 - add scim-pinyin-showallkeys.patch * Mon Feb 13 2006 Jens Petersen - remove superfluous post and postun scripts * Mon Feb 13 2006 Qian Shen - 0.5.91-4.2 - add scim-pinyin-shuangpin.patch selinux-policy-2.2.14-2 ----------------------- * Mon Feb 13 2006 Dan Walsh 2.2.14-2 - Add users_extra files * Fri Feb 10 2006 Dan Walsh 2.2.14-1 - Update to upstream shared-mime-info-0.16.cvs20060212-3 ----------------------------------- * Mon Feb 13 2006 Ray Strode - 0.16.cvs20060212-3 - add gthumb as fallback * Mon Feb 13 2006 Ray Strode - 0.16.cvs20060212-2 - make eog the default image viewer tomboy-0.3.5-2 -------------- * Sun Feb 12 2006 Christopher Aillon - 0.3.5-2 - Rebuild totem-1.3.91-1 -------------- * Mon Feb 13 2006 Matthias Clasen - 1.3.91-1 - Update to 1.3.91 xchat-1:2.6.0-4 --------------- * Sun Feb 12 2006 Christopher Aillon - 1:2.6.0-4 - Rebuild xterm-209-1 ----------- * Tue Feb 14 2006 Jason Vas Dias - 209-1 - Upgrade to upstream version 209 (fixes bug 180450) yp-tools-2.9-0 -------------- * Mon Feb 13 2006 Chris Feist - 2.9-0 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 2.8-8.2 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 09 2005 Jesse Keating - rebuilt ypbind-3:1.19-0 --------------- * Mon Feb 13 2006 Chris Feist - 3:1.19 - Build for latest version of ypbind-mt ypserv-2.19-0 ------------- * Mon Feb 13 2006 Chris Feist - 2.19-0 - Rebuilt against latest upstream sources (2.19). Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15-4.i686 requires kernel = 0:2.6.15-1.1941_FC5 GFS-kernel - 2.6.15-4.i686 requires /lib/modules/2.6.15-1.1941_FC5 GFS-kernel-smp - 2.6.15-4.i686 requires kernel-smp = 0:2.6.15-1.1941_FC5 GFS-kernel-smp - 2.6.15-4.i686 requires /lib/modules/2.6.15-1.1941_FC5smp cman-kernel - 2.6.15.0-20051219.162641.FC5.11.4.i686 requires kernel = 0:2.6.15-1.1941_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.4.i686 requires /lib/modules/2.6.15-1.1941_FC5 cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.4.i686 requires kernel-smp = 0:2.6.15-1.1941_FC5 cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.4.i686 requires /lib/modules/2.6.15-1.1941_FC5smp dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.3.i686 requires kernel = 0:2.6.15-1.1941_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.3.i686 requires /lib/modules/2.6.15-1.1941_FC5 dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.3.i686 requires kernel-smp = 0:2.6.15-1.1941_FC5 dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.3.i686 requires /lib/modules/2.6.15-1.1941_FC5smp gnbd-kernel - 2.6.15-3.i686 requires kernel = 0:2.6.15-1.1941_FC5 gnbd-kernel - 2.6.15-3.i686 requires /lib/modules/2.6.15-1.1941_FC5 gnbd-kernel-smp - 2.6.15-3.i686 requires kernel-smp = 0:2.6.15-1.1941_FC5 gnbd-kernel-smp - 2.6.15-3.i686 requires /lib/modules/2.6.15-1.1941_FC5smp Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs vconfig - 1.9-1.1.ia64 requires libc.so.6 vconfig - 1.9-1.1.ia64 requires libc.so.6(GLIBC_2.0) Broken deps for ppc ---------------------------------------------------------- ccs-devel - 1.0.3-0.2.ppc requires ccs = 0:1.0.3-0.2 gulm - 1.0.0-2.ppc requires ccs Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 magma-plugins - 1.0.3-1.FC5.ppc64 requires libgulm.so.1()(64bit) vconfig - 1.9-1.1.ppc64 requires libc.so.6 vconfig - 1.9-1.1.ppc64 requires libc.so.6(GLIBC_2.0) Broken deps for s390 ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 Broken deps for s390x ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15-4.x86_64 requires kernel = 0:2.6.15-1.1941_FC5 GFS-kernel - 2.6.15-4.x86_64 requires /lib/modules/2.6.15-1.1941_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.4.x86_64 requires kernel = 0:2.6.15-1.1941_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.4.x86_64 requires /lib/modules/2.6.15-1.1941_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.3.x86_64 requires kernel = 0:2.6.15-1.1941_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.3.x86_64 requires /lib/modules/2.6.15-1.1941_FC5 gnbd-kernel - 2.6.15-3.x86_64 requires kernel = 0:2.6.15-1.1941_FC5 gnbd-kernel - 2.6.15-3.x86_64 requires /lib/modules/2.6.15-1.1941_FC5 From mailinglists at erwinrol.com Tue Feb 14 10:51:43 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Tue, 14 Feb 2006 11:51:43 +0100 Subject: rawhide report: 20060214 changes In-Reply-To: <200602140839.k1E8dgJl007784@porkchop.devel.redhat.com> References: <200602140839.k1E8dgJl007784@porkchop.devel.redhat.com> Message-ID: <1139914304.17385.133.camel@xpc.home.erwinrol.com> With today's update i noticed the following, i dunno if it is a bug or some broken script: Cleanup : GConf ##################### [382/415] /sbin/ldconfig: relative path `2' used to build cache error: %postun(GConf-1.0.9-18.x86_64) scriptlet failed, exit status 1 - Erwin From hughsient at gmail.com Tue Feb 14 12:06:07 2006 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 14 Feb 2006 12:06:07 +0000 Subject: gnome-power-manager quits unexpectedly In-Reply-To: References: <4b3752c70602122012n73a21d1bic65b6c926247f8db@mail.gmail.com> <15e53e180602130204r3ad5c492i@mail.gmail.com> <43F0EE07.1070501@stasis.org> Message-ID: <1139918767.3848.3.camel@localhost.localdomain> On Mon, 2006-02-13 at 21:52 +0000, leon wrote: > Rowan Kerr writes: > > | Richard Hughes wrote: > | > On 13/02/06, S Baig wrote: > | >> ** ERROR **: This program cannot start until you start the dbus session > | >> daemon > | >> This is usually started in X or gnome startup (depending on distro) > | >> You can launch the session dbus-daemon manually with this command: > | >> eval `dbus-launch --auto-syntax` > | >> > | >> > | >> I cannot find 'dbus-launch' anywhere in my path, but I verified using > | >> 'system-config-services' that the messagebus service is running. Has anyone > | >> else had this problem? > | > Do you have dbus-x11 installed? > | > | I get the same problem persistently since installing from fc5t2 and > | upgrading to rawhide. (I just did another update this morning). > | > | dbus-x11 is: dbux-x11-0.60-7.2 and messagebus is set to run on startup. > | > | I get another message about selinux: > | ** (gnome-power-manager:2347):WARNING **: main: an SELinux policy > | prevents this sender from sending this message... (rejected message > | had interface "org.freedesktop.DBus" member "Hello" error name > | "(unset") destination "org.freedeesktop.DBus") > | > | Is there somewhere I should be resetting my selinux config or > | what.. > > This bug has been hanging around for a while. My laptop can't do > suspend/hibernate. Hope it get fixed when test3 released. I'm guessing turning selinux off fixes the problem. What does the avc log say? Richard. From sdl.web at gmail.com Tue Feb 14 12:22:38 2006 From: sdl.web at gmail.com (leon) Date: Tue, 14 Feb 2006 12:22:38 +0000 Subject: gnome-power-manager quits unexpectedly References: <4b3752c70602122012n73a21d1bic65b6c926247f8db@mail.gmail.com> <15e53e180602130204r3ad5c492i@mail.gmail.com> <43F0EE07.1070501@stasis.org> <1139918767.3848.3.camel@localhost.localdomain> Message-ID: Indeed. But there is no suspend/hibernate options from gnome-power-manager. Richard Hughes writes: | On Mon, 2006-02-13 at 21:52 +0000, leon wrote: | > Rowan Kerr writes: | > | > | Richard Hughes wrote: | > | > On 13/02/06, S Baig wrote: | > | >> ** ERROR **: This program cannot start until you start the dbus session | > | >> daemon | > | >> This is usually started in X or gnome startup (depending on distro) | > | >> You can launch the session dbus-daemon manually with this command: | > | >> eval `dbus-launch --auto-syntax` | > | >> | > | >> | > | >> I cannot find 'dbus-launch' anywhere in my path, but I verified using | > | >> 'system-config-services' that the messagebus service is running. Has anyone | > | >> else had this problem? | > | > Do you have dbus-x11 installed? | > | | > | I get the same problem persistently since installing from fc5t2 and | > | upgrading to rawhide. (I just did another update this morning). | > | | > | dbus-x11 is: dbux-x11-0.60-7.2 and messagebus is set to run on startup. | > | | > | I get another message about selinux: | > | ** (gnome-power-manager:2347):WARNING **: main: an SELinux policy | > | prevents this sender from sending this message... (rejected message | > | had interface "org.freedesktop.DBus" member "Hello" error name | > | "(unset") destination "org.freedeesktop.DBus") | > | | > | Is there somewhere I should be resetting my selinux config or | > | what.. | > | > This bug has been hanging around for a while. My laptop can't do | > suspend/hibernate. Hope it get fixed when test3 released. | | I'm guessing turning selinux off fixes the problem. What does the avc | log say? | | Richard. -- Leon From sundaram at fedoraproject.org Tue Feb 14 12:29:15 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 14 Feb 2006 17:59:15 +0530 Subject: gnome-power-manager quits unexpectedly In-Reply-To: References: <4b3752c70602122012n73a21d1bic65b6c926247f8db@mail.gmail.com> <15e53e180602130204r3ad5c492i@mail.gmail.com> <43F0EE07.1070501@stasis.org> <1139918767.3848.3.camel@localhost.localdomain> Message-ID: <43F1CD1B.6070007@fedoraproject.org> leon wrote: >Indeed. But there is no suspend/hibernate options from gnome-power-manager. > > Check the rawhide reports change log. gnome-power-manager-2.13.5.0.20060207-2 --------------------------------------- * Mon Feb 13 2006 Ray Strode - 2.13.5.0.20060207-2 - remove Hibernate and Suspend from menus as part of panel/g-p-m integration effort -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From hughsient at gmail.com Tue Feb 14 12:34:31 2006 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 14 Feb 2006 12:34:31 +0000 Subject: gnome-power-manager quits unexpectedly In-Reply-To: <43F1CD1B.6070007@fedoraproject.org> References: <4b3752c70602122012n73a21d1bic65b6c926247f8db@mail.gmail.com> <15e53e180602130204r3ad5c492i@mail.gmail.com> <43F0EE07.1070501@stasis.org> <1139918767.3848.3.camel@localhost.localdomain> <43F1CD1B.6070007@fedoraproject.org> Message-ID: <1139920471.3848.6.camel@localhost.localdomain> On Tue, 2006-02-14 at 17:59 +0530, Rahul Sundaram wrote: > leon wrote: > > >Indeed. But there is no suspend/hibernate options from gnome-power-manager. > > > > > Check the rawhide reports change log. > > gnome-power-manager-2.13.5.0.20060207-2 > > --------------------------------------- > * Mon Feb 13 2006 Ray Strode - 2.13.5.0.20060207-2 > - remove Hibernate and Suspend from menus as part of > panel/g-p-m integration effort Indeed (just installing a new rawhide so I can see the effect...), if that doesn't work you can use the g-p-m dbus interface: dbus-send --session \ --dest=org.gnome.PowerManager \ --type=method_call \ --print-reply \ --reply-timeout=2000 \ /org/gnome/PowerManager \ org.gnome.PowerManager.Hibernate Richard. From pbrobinson at gmail.com Tue Feb 14 12:48:29 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 14 Feb 2006 12:48:29 +0000 Subject: gnome-power-manager quits unexpectedly In-Reply-To: <43F1CD1B.6070007@fedoraproject.org> References: <4b3752c70602122012n73a21d1bic65b6c926247f8db@mail.gmail.com> <15e53e180602130204r3ad5c492i@mail.gmail.com> <43F0EE07.1070501@stasis.org> <1139918767.3848.3.camel@localhost.localdomain> <43F1CD1B.6070007@fedoraproject.org> Message-ID: <5256d0b0602140448o7988d7dcr7685194de4d18dfb@mail.gmail.com> > >Indeed. But there is no suspend/hibernate options from gnome-power-manager. > > > > > Check the rawhide reports change log. > > gnome-power-manager-2.13.5.0.20060207-2 > > --------------------------------------- > * Mon Feb 13 2006 Ray Strode - 2.13.5.0.20060207-2 > - remove Hibernate and Suspend from menus as part of > panel/g-p-m integration effort It appears that the suspend has replaced the shutdown option in the desktop menu. Are we allowed to shut down or reboot anymore :-) Surely it should be part of the option 'suspend|shutdown|reboot' Pete From tjb at unh.edu Tue Feb 14 13:50:58 2006 From: tjb at unh.edu (Thomas J. Baker) Date: Tue, 14 Feb 2006 08:50:58 -0500 Subject: GDM In-Reply-To: References: <1139857556.2578.3.camel@beast.rexursive.com> <1139860070.2587.4.camel@halflap> <1139861771.16457.2.camel@intrepid> <1139865227.16457.7.camel@intrepid> <003301c630e4$412ef130$0301a8c0@miketc.com> Message-ID: <1139925058.7788.2.camel@zero.sr.unh.edu> On Mon, 2006-02-13 at 16:36 -0500, Jon Nettleton wrote: > > > On 2/13/06, Mike Chambers wrote: > ----- Original Message ----- > From: "Thomas J. Baker" > To: "Development discussions related to Fedora Core" > > Sent: Monday, February 13, 2006 3:13 PM > Subject: Re: GDM > > > > > It doesn't appear my problems are related to gdm. Even at > runlevel 3, > > startx bombs out too. The biggest suck is that there don't > seem to be > > any error messages anywhere... > > I am experiencing the same problem as you are, even in run > level 3. If you > try to run gdmsetup, I get an Gtk-Warning error. I hope that > whoever fixes > this > one, would hopefully post a working copy of the rpm somewhere > (people.redhat.com server would work) until it hits rawhide. > > Thanks, > > Mike Chambers > Madisonville, KY > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > This problem appears to be two fold. I fixed /etc/gdm/custom.conf, > but still could not log in to an X session. I had to move my .fonts > directory to .fonts-bak and then gnome-session stopped crashing. I > haven't had time to debug it, or file a bug yet. Maybe later > tonight. > > Jon > I still had the same problem after todays update. I removed the fonts.cache\* files in my .fonts directory and now everything works again. 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 Feb 14 13:52:37 2006 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 14 Feb 2006 05:52:37 -0800 (PST) Subject: snort inline on Fedora In-Reply-To: <1139877312.15916.7.camel@cosima.et.endace.com> Message-ID: <20060214135237.41573.qmail@web51508.mail.yahoo.com> >Ok, so do I go back to snort and find out whats what or does RH update >glibc-kernheaders? Isn't inline snort a kernel patch? If so it has to be applied to the kernel or something like that. The code for snort is very buggy. I did a code review a while back and was not happy with what I saw. The code I saw could get you hacked due to poor programming practices. I reported this on their mail list to no avail. I'd be very careful how I add snort to a network. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From rmo at sunnmore.net Tue Feb 14 15:18:42 2006 From: rmo at sunnmore.net (Roy-Magne Mo) Date: Tue, 14 Feb 2006 16:18:42 +0100 Subject: hypervisor-2.6.15-1.51_FC5 panics. In-Reply-To: <1139825486.2555.1.camel@dragon.sys.intra> References: <1139825486.2555.1.camel@dragon.sys.intra> Message-ID: <1139930322.4064.10.camel@host-81-191-138-132.bluecom.no> m? den 13.02.2006 klokka 19:11 (+0900) skreiv Naoki: > >From a few days back and including latest rawhide > kernel-xen-hypervisor-2.6.15-1.51_FC5 panics on boot. > > Do we know about this or should I bz it? Sorry I didn't get a look at > the panic message because it reboots too quickly but it was not long > after loading. 2.6.15-1.1948_FC5hypervisor boots for me, so this was probably a fluke :) From ndbecker2 at gmail.com Tue Feb 14 15:56:34 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 14 Feb 2006 10:56:34 -0500 Subject: No kde power applet after today's update Message-ID: Don't even recall what it's called, but my kde panel used to have an applet that showed battery/online status, now it's missing. Don't know where to look for error messages (nothing interesting in /var/log/messages) From ndbecker2 at gmail.com Tue Feb 14 16:28:29 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 14 Feb 2006 11:28:29 -0500 Subject: No kde power applet after today's update References: Message-ID: Neal Becker wrote: > Don't even recall what it's called, but my kde panel used to have an > applet > that showed battery/online status, now it's missing. Don't know where to > look for error messages (nothing interesting in /var/log/messages) > I see. klaptop is now displaying an applet in the upper left corner, not in panel. OK. From mandreiana.lists at gmail.com Tue Feb 14 16:40:34 2006 From: mandreiana.lists at gmail.com (Marius Andreiana) Date: Tue, 14 Feb 2006 18:40:34 +0200 Subject: interesting benchmark of OOo performance (FC5 t2) Message-ID: <4bcf41a00602140840v722488d5sea091832da58c47e@mail.gmail.com> Hi, Quoting Dan Kegel from http://www.winehq.org/?issue=305 To see how reasonable it might be to use OOo 2.0.1 and Firefox 1.5 under Wine routinely, I benchmarked their startup time on a Fedora Core 5 test 2 system under four conditions: native vs. with wine from cvs, and with 416MB RAM vs. 96 MB RAM (by booting with mem=96M; this was to simulate running on one of those cheapo 128MB boxes that uses shared video RAM). This was on a zippy Compaq Presario 3000 Athlon 64 3000+. All apps were downloaded from openoffice.org and mozilla.com. Results for first run of app after booting (1st column is startup time): 5 Firefox run1 native 416MB 12 Firefox run1 wine 416MB 11 Firefox run1 native 96MB 15 Firefox run1 wine 96MB 11 ooo run1 native 416MB 15 ooo run1 wine 416MB 60 ooo run1 native 96MB 37 ooo run1 wine 96MB So wine is 1.4 to 2.5 times slower at app startup generally, but when ram is really short, win32 openoffice starts up with wine 1.5 times *faster* than the native linux version! (Maybe because the Microsoft tools are better at avoiding I/O or relocations during loading?) I then measured how long it took to start up the app the second time, when the cache was nice and hot: 3 Firefox run2 native 416MB 4 Firefox run2 wine 416MB 4 ooo run2 native 416MB 6 ooo run2 wine 416MB 4 Firefox run2 native 96MB 6 Firefox run2 wine 96MB 36 ooo run2 native 96MB 28 ooo run2 wine 96MB The times are uniformly faster on the second run, but the patter holds, i.e. wine is 1.4-1.5 times slower than native generally, but win32 openoffice under wine is 1.5 times *faster* than the native version when starved for RAM. There was concern FC5 might be throwing off the results, but Dan tried with Ubuntu 5.10 and found similar results. == Do you have any suggestions of the cause that OOo Linux version is slower than Windows one? -- Marius Andreiana From johnp at redhat.com Tue Feb 14 16:42:16 2006 From: johnp at redhat.com (John (J5) Palmieri) Date: Tue, 14 Feb 2006 11:42:16 -0500 Subject: No kde power applet after today's update In-Reply-To: References: Message-ID: <1139935336.30456.48.camel@remedyz.boston.redhat.com> On Tue, 2006-02-14 at 10:56 -0500, Neal Becker wrote: > Don't even recall what it's called, but my kde panel used to have an applet > that showed battery/online status, now it's missing. Don't know where to > look for error messages (nothing interesting in /var/log/messages) This is due to HAL not starting because of SELinux rules. -- John (J5) Palmieri From seandarcy2 at gmail.com Tue Feb 14 16:28:53 2006 From: seandarcy2 at gmail.com (sean) Date: Tue, 14 Feb 2006 11:28:53 -0500 Subject: can anybody install gnome-volume-manager? In-Reply-To: <1139902787.28615.15.camel@laurel.intra.city-fan.org> References: <1139902787.28615.15.camel@laurel.intra.city-fan.org> Message-ID: Paul Howarth wrote: > On Mon, 2006-02-13 at 22:40 -0500, sean wrote: > >>on amd64: >> >>rpm -Uvh gnome-volume-manager-1.5.11-1.2.x86_64.rpm >>Preparing... >>########################################### [100%] >> 1:gnome-volume-manager >>########################################### [100%] >>error: unpacking of archive failed on file >>/usr/bin/magicdev: cpio: rename failed - Operation not permitted >> >>I've also rebuilt from the src.rpm. Same result. Looked at >>the spec file. Nothing odd. >> >>Am I missing some magic handshake? > > > What's /usr/bin/magicdev on your system? > > $ ls -l /usr/bin/magicdev > > And what is it in the rpm? > > $ rpm -qlpv gnome-volume-manager-1.5.11-1.2.x86_64.rpm | grep > -F /usr/bin/magicdev > > Paul. > ls -l /usr/bin/magicdev -rw-r--r-- 1 root root 0 Feb 26 2003 /usr/bin/magicdev rpm -qlpv gnome-volume-manager-1.5.11-1.2.x86_64.rpm | grep -F /usr/bin/magicdev -rwxr-xr-x 1 root root 262 Feb 13 22:32 /usr/bin/magicdev sean From paul at city-fan.org Tue Feb 14 16:53:39 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 14 Feb 2006 16:53:39 +0000 Subject: can anybody install gnome-volume-manager? In-Reply-To: References: <1139902787.28615.15.camel@laurel.intra.city-fan.org> Message-ID: <43F20B13.2020800@city-fan.org> sean wrote: > Paul Howarth wrote: > >> On Mon, 2006-02-13 at 22:40 -0500, sean wrote: >> >>> on amd64: >>> >>> rpm -Uvh gnome-volume-manager-1.5.11-1.2.x86_64.rpm >>> Preparing... ########################################### [100%] >>> 1:gnome-volume-manager ########################################### >>> [100%] >>> error: unpacking of archive failed on file /usr/bin/magicdev: cpio: >>> rename failed - Operation not permitted >>> >>> I've also rebuilt from the src.rpm. Same result. Looked at the spec >>> file. Nothing odd. >>> >>> Am I missing some magic handshake? >> >> >> >> What's /usr/bin/magicdev on your system? >> >> $ ls -l /usr/bin/magicdev >> >> And what is it in the rpm? >> >> $ rpm -qlpv gnome-volume-manager-1.5.11-1.2.x86_64.rpm | grep >> -F /usr/bin/magicdev >> >> Paul. >> > > ls -l /usr/bin/magicdev > -rw-r--r-- 1 root root 0 Feb 26 2003 /usr/bin/magicdev > > rpm -qlpv gnome-volume-manager-1.5.11-1.2.x86_64.rpm | grep -F > /usr/bin/magicdev > -rwxr-xr-x 1 root root 262 Feb 13 22:32 > /usr/bin/magicdev Curious; it seems to be just a regular file in both cases. This problem usually manifests itself when one is a file and the other is a directory. Can you try removing or renaming /usr/bin/magicdev before installing the RPM? Paul. From nicolas.mailhot at laposte.net Tue Feb 14 17:04:36 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 14 Feb 2006 18:04:36 +0100 (CET) Subject: interesting benchmark of OOo performance (FC5 t2) In-Reply-To: <4bcf41a00602140840v722488d5sea091832da58c47e@mail.gmail.com> References: <4bcf41a00602140840v722488d5sea091832da58c47e@mail.gmail.com> Message-ID: <5446.192.54.193.25.1139936676.squirrel@rousalka.dyndns.org> Le Mar 14 f?vrier 2006 17:40, Marius Andreiana a ?crit : > Do you have any suggestions of the cause that OOo Linux version is > slower than Windows one? You're probably comparing apples with oranges. The native OO.o has lots of translation packs included, access to system resources (like fonts...) I strongly suspect your wine test version OTOH has a lot less stuff in it. -- Nicolas Mailhot From seandarcy2 at gmail.com Tue Feb 14 17:24:37 2006 From: seandarcy2 at gmail.com (sean) Date: Tue, 14 Feb 2006 12:24:37 -0500 Subject: can anybody install gnome-volume-manager? In-Reply-To: <43F20B13.2020800@city-fan.org> References: <1139902787.28615.15.camel@laurel.intra.city-fan.org> <43F20B13.2020800@city-fan.org> Message-ID: Paul Howarth wrote: > sean wrote: > >> Paul Howarth wrote: >> >>> On Mon, 2006-02-13 at 22:40 -0500, sean wrote: >>> >>>> on amd64: >>>> >>>> rpm -Uvh gnome-volume-manager-1.5.11-1.2.x86_64.rpm >>>> Preparing... ########################################### [100%] >>>> 1:gnome-volume-manager >>>> ########################################### [100%] >>>> error: unpacking of archive failed on file /usr/bin/magicdev: cpio: >>>> rename failed - Operation not permitted >>>> >>>> I've also rebuilt from the src.rpm. Same result. Looked at the spec >>>> file. Nothing odd. >>>> >>>> Am I missing some magic handshake? >>> >>> >>> >>> >>> What's /usr/bin/magicdev on your system? >>> >>> $ ls -l /usr/bin/magicdev >>> >>> And what is it in the rpm? >>> >>> $ rpm -qlpv gnome-volume-manager-1.5.11-1.2.x86_64.rpm | grep >>> -F /usr/bin/magicdev >>> >>> Paul. >>> >> >> ls -l /usr/bin/magicdev >> -rw-r--r-- 1 root root 0 Feb 26 2003 /usr/bin/magicdev >> >> rpm -qlpv gnome-volume-manager-1.5.11-1.2.x86_64.rpm | grep -F >> /usr/bin/magicdev >> -rwxr-xr-x 1 root root 262 Feb 13 22:32 >> /usr/bin/magicdev > > > Curious; it seems to be just a regular file in both cases. This problem > usually manifests itself when one is a file and the other is a > directory. Can you try removing or renaming /usr/bin/magicdev before > installing the RPM? > > Paul. > Really curious. Look: [root at amd64-3000 development]# rpm -qif /usr/bin/magicdev file /usr/bin/magicdev is not owned by any package [root at amd64-3000 development]# rm -f /usr/bin/magicdev rm: cannot remove `/usr/bin/magicdev': Operation not permitted [root at amd64-3000 development]# chmod 777 /usr/bin/magicdev chmod: changing permissions of `/usr/bin/magicdev': Operation not permitted [root at amd64-3000 development]# mv /usr/bin/magicdev . mv: cannot move `/usr/bin/magicdev' to `./magicdev': Operation not permitted ???? sean From sundaram at fedoraproject.org Tue Feb 14 17:41:06 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 14 Feb 2006 23:11:06 +0530 Subject: Bugzilla dupes attack Message-ID: <43F21632.1000003@fedoraproject.org> Hi Save us a few hours of bugzilla grunt work by not filing two hundred and seventeen duplicates for a trivial bug. Thanks. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181064 If anyone has a list of good improvements that can be made to bugzilla to help is triaging let me know. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From paul at city-fan.org Tue Feb 14 17:52:39 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 14 Feb 2006 17:52:39 +0000 Subject: can anybody install gnome-volume-manager? In-Reply-To: References: <1139902787.28615.15.camel@laurel.intra.city-fan.org> <43F20B13.2020800@city-fan.org> Message-ID: <43F218E7.9020305@city-fan.org> sean wrote: > Paul Howarth wrote: > >> sean wrote: >> >>> Paul Howarth wrote: >>> >>>> On Mon, 2006-02-13 at 22:40 -0500, sean wrote: >>>> >>>>> on amd64: >>>>> >>>>> rpm -Uvh gnome-volume-manager-1.5.11-1.2.x86_64.rpm >>>>> Preparing... ########################################### [100%] >>>>> 1:gnome-volume-manager >>>>> ########################################### [100%] >>>>> error: unpacking of archive failed on file /usr/bin/magicdev: cpio: >>>>> rename failed - Operation not permitted >>>>> >>>>> I've also rebuilt from the src.rpm. Same result. Looked at the spec >>>>> file. Nothing odd. >>>>> >>>>> Am I missing some magic handshake? >>>> >>>> >>>> >>>> >>>> >>>> What's /usr/bin/magicdev on your system? >>>> >>>> $ ls -l /usr/bin/magicdev >>>> >>>> And what is it in the rpm? >>>> >>>> $ rpm -qlpv gnome-volume-manager-1.5.11-1.2.x86_64.rpm | grep >>>> -F /usr/bin/magicdev >>>> >>>> Paul. >>>> >>> >>> ls -l /usr/bin/magicdev >>> -rw-r--r-- 1 root root 0 Feb 26 2003 /usr/bin/magicdev >>> >>> rpm -qlpv gnome-volume-manager-1.5.11-1.2.x86_64.rpm | grep -F >>> /usr/bin/magicdev >>> -rwxr-xr-x 1 root root 262 Feb 13 22:32 >>> /usr/bin/magicdev >> >> >> >> Curious; it seems to be just a regular file in both cases. This >> problem usually manifests itself when one is a file and the other is a >> directory. Can you try removing or renaming /usr/bin/magicdev before >> installing the RPM? >> >> Paul. >> > > Really curious. Look: > > [root at amd64-3000 development]# rpm -qif /usr/bin/magicdev > file /usr/bin/magicdev is not owned by any package > [root at amd64-3000 development]# rm -f /usr/bin/magicdev > rm: cannot remove `/usr/bin/magicdev': Operation not permitted > [root at amd64-3000 development]# chmod 777 /usr/bin/magicdev > chmod: changing permissions of `/usr/bin/magicdev': Operation not permitted > [root at amd64-3000 development]# mv /usr/bin/magicdev . > mv: cannot move `/usr/bin/magicdev' to `./magicdev': Operation not > permitted Maybe it's immutable: # lsattr /usr/bin/magicdev Paul. From lsomike at futzin.com Tue Feb 14 17:56:31 2006 From: lsomike at futzin.com (Mike Klinke) Date: Tue, 14 Feb 2006 11:56:31 -0600 Subject: Bugzilla dupes attack In-Reply-To: <43F21632.1000003@fedoraproject.org> References: <43F21632.1000003@fedoraproject.org> Message-ID: <200602141156.31901.lsomike@futzin.com> On Tuesday 14 February 2006 11:41, Rahul Sundaram wrote: > Save us a few hours of bugzilla grunt work by not filing two > hundred and seventeen duplicates for a trivial bug. Thanks. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181064 > > If anyone has a list of good improvements that can be made to > bugzilla to help is triaging let me know. Over the years the single biggest complaint voiced on these lists is the poor search results bugzilla provides. If the searches provided better results perhaps duplcatess wouldn't be so prevalent. Regards, Mike Klinke From dlutter at redhat.com Tue Feb 14 18:02:45 2006 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 14 Feb 2006 10:02:45 -0800 Subject: Bugzilla dupes attack In-Reply-To: <43F21632.1000003@fedoraproject.org> References: <43F21632.1000003@fedoraproject.org> Message-ID: <1139940165.1158.2.camel@currant.watzmann.net> On Tue, 2006-02-14 at 23:11 +0530, Rahul Sundaram wrote: > Save us a few hours of bugzilla grunt work by not filing two hundred and > seventeen duplicates for a trivial bug. Thanks. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181064 > > If anyone has a list of good improvements that can be made to bugzilla > to help is triaging let me know. I assume the two hundred and seventeen duplicates were caused by a malfunction of the left mouse button. In this case, double-click protection would have done the trick, i.e. generate a token when generating the initial form and only accept the first submission of the form with that token. Or search for existing bugzillas with identical text upon submission. David From sundaram at fedoraproject.org Tue Feb 14 18:08:31 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 14 Feb 2006 23:38:31 +0530 Subject: Bugzilla dupes attack In-Reply-To: <200602141156.31901.lsomike@futzin.com> References: <43F21632.1000003@fedoraproject.org> <200602141156.31901.lsomike@futzin.com> Message-ID: <43F21C9F.4010904@fedoraproject.org> Mike Klinke wrote: >On Tuesday 14 February 2006 11:41, Rahul Sundaram wrote: > > > >>Save us a few hours of bugzilla grunt work by not filing two >>hundred and seventeen duplicates for a trivial bug. Thanks. >> >>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181064 >> >>If anyone has a list of good improvements that can be made to >>bugzilla to help is triaging let me know. >> >> > >Over the years the single biggest complaint voiced on these lists is >the poor search results bugzilla provides. If the searches >provided better results perhaps duplcatess wouldn't be so >prevalent. > > That was not the case for this bug report. Give me specific instances where bugzilla search didnt provide the results you wanted out of it while it already had the content you were looking and copy the mails to dkl AT redhat.com. I suspect a lot of these complaints are wrong user queries. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From sundaram at fedoraproject.org Tue Feb 14 18:10:37 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 14 Feb 2006 23:40:37 +0530 Subject: Bugzilla dupes attack In-Reply-To: <1139940165.1158.2.camel@currant.watzmann.net> References: <43F21632.1000003@fedoraproject.org> <1139940165.1158.2.camel@currant.watzmann.net> Message-ID: <43F21D1D.80907@fedoraproject.org> David Lutterkort wrote: >On Tue, 2006-02-14 at 23:11 +0530, Rahul Sundaram wrote: > > >>Save us a few hours of bugzilla grunt work by not filing two hundred and >>seventeen duplicates for a trivial bug. Thanks. >> >>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181064 >> >>If anyone has a list of good improvements that can be made to bugzilla >>to help is triaging let me know. >> >> > >I assume the two hundred and seventeen duplicates were caused by a >malfunction of the left mouse button. > >In this case, double-click protection would have done the trick, i.e. >generate a token when generating the initial form and only accept the >first submission of the form with that token. Or search for existing >bugzillas with identical text upon submission. > > Kindly add your comments to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=28151. Thanks. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From mailinglists at erwinrol.com Tue Feb 14 18:13:13 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Tue, 14 Feb 2006 19:13:13 +0100 Subject: Bugzilla dupes attack In-Reply-To: <43F21C9F.4010904@fedoraproject.org> References: <43F21632.1000003@fedoraproject.org> <200602141156.31901.lsomike@futzin.com> <43F21C9F.4010904@fedoraproject.org> Message-ID: <1139940793.17385.181.camel@xpc.home.erwinrol.com> On Tue, 2006-02-14 at 23:38 +0530, Rahul Sundaram wrote: > Mike Klinke wrote: > That was not the case for this bug report. Give me specific instances > where bugzilla search didnt provide the results you wanted out of it > while it already had the content you were looking and copy the mails to > dkl AT redhat.com. I suspect a lot of these complaints are wrong user > queries. When it is so easy to do a wrong query, there might be something wrong with the software and not with the user ;-) - Erwin From sundaram at fedoraproject.org Tue Feb 14 18:18:16 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 14 Feb 2006 23:48:16 +0530 Subject: Bugzilla dupes attack In-Reply-To: <1139940793.17385.181.camel@xpc.home.erwinrol.com> References: <43F21632.1000003@fedoraproject.org> <200602141156.31901.lsomike@futzin.com> <43F21C9F.4010904@fedoraproject.org> <1139940793.17385.181.camel@xpc.home.erwinrol.com> Message-ID: <43F21EE8.3020001@fedoraproject.org> Erwin Rol wrote: >On Tue, 2006-02-14 at 23:38 +0530, Rahul Sundaram wrote: > > >>Mike Klinke wrote: >> >> > > > >>That was not the case for this bug report. Give me specific instances >>where bugzilla search didnt provide the results you wanted out of it >>while it already had the content you were looking and copy the mails to >>dkl AT redhat.com. I suspect a lot of these complaints are wrong user >>queries. >> >> > >When it is so easy to do a wrong query, there might be something wrong >with the software and not with the user ;-) > > > Please be specific enough and provide examples.What is the current results and what is expected in the search query?. If you are talking about interface improvements can you provide mockups?. If not what can you do to help? -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From rowan at stasis.org Tue Feb 14 18:21:00 2006 From: rowan at stasis.org (Rowan Kerr) Date: Tue, 14 Feb 2006 13:21:00 -0500 Subject: gnome-power-manager quits unexpectedly In-Reply-To: <1139918767.3848.3.camel@localhost.localdomain> References: <4b3752c70602122012n73a21d1bic65b6c926247f8db@mail.gmail.com> <15e53e180602130204r3ad5c492i@mail.gmail.com> <43F0EE07.1070501@stasis.org> <1139918767.3848.3.camel@localhost.localdomain> Message-ID: <43F21F8C.5010905@stasis.org> Richard Hughes wrote: > I'm guessing turning selinux off fixes the problem. What does the avc > log say? /var/log/audit/audit.log says something like... type=USER_AVC msg=audit(1139940939.476:4123): user pid=1528 uid=81 auid=4294967295 msg='avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.DBus member=Hello dest=org.freedesktop.DBus spid=2994 scontext=user_u:system_r:unconfined_t tcontext=system_u:system_r:initrc_t tclass=dbus : exe="?" (sauid=81, hostname=?, addr=?, terminal=?)' Not that I have an idea what that means :) I haven't ever run with selinux enabled before. From michael at knox.net.nz Tue Feb 14 18:19:33 2006 From: michael at knox.net.nz (Michael J Knox) Date: Wed, 15 Feb 2006 07:19:33 +1300 Subject: snort inline on Fedora In-Reply-To: <20060214135237.41573.qmail@web51508.mail.yahoo.com> References: <20060214135237.41573.qmail@web51508.mail.yahoo.com> Message-ID: <1139941174.19452.0.camel@cosima.et.endace.com> On Tue, 2006-02-14 at 05:52 -0800, Steve G wrote: > >Ok, so do I go back to snort and find out whats what or does RH update > >glibc-kernheaders? > > Isn't inline snort a kernel patch? If so it has to be applied to the kernel or > something like that. > > The code for snort is very buggy. I did a code review a while back and was not > happy with what I saw. The code I saw could get you hacked due to poor > programming practices. I reported this on their mail list to no avail. I'd be > very careful how I add snort to a network. No inline is not a kernel patch. Michael From lsomike at futzin.com Tue Feb 14 18:24:52 2006 From: lsomike at futzin.com (Mike Klinke) Date: Tue, 14 Feb 2006 12:24:52 -0600 Subject: Bugzilla dupes attack In-Reply-To: <43F21EE8.3020001@fedoraproject.org> References: <43F21632.1000003@fedoraproject.org> <1139940793.17385.181.camel@xpc.home.erwinrol.com> <43F21EE8.3020001@fedoraproject.org> Message-ID: <200602141224.52515.lsomike@futzin.com> On Tuesday 14 February 2006 12:18, Rahul Sundaram wrote: > Please be specific enough and provide examples.What is the > current results and what is expected in the search query?. Plug "Sundarm" into the initial bugzilla quick search and compare the results by plugging: "Sundaram site:bugzilla.redhat.com" into Google. Regards, Mike Klinke From sundaram at fedoraproject.org Tue Feb 14 18:25:53 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 14 Feb 2006 23:55:53 +0530 Subject: gnome-power-manager quits unexpectedly In-Reply-To: <43F21F8C.5010905@stasis.org> References: <4b3752c70602122012n73a21d1bic65b6c926247f8db@mail.gmail.com> <15e53e180602130204r3ad5c492i@mail.gmail.com> <43F0EE07.1070501@stasis.org> <1139918767.3848.3.camel@localhost.localdomain> <43F21F8C.5010905@stasis.org> Message-ID: <43F220B1.1070201@fedoraproject.org> Rowan Kerr wrote: > Richard Hughes wrote: > >> I'm guessing turning selinux off fixes the problem. What does the avc >> log say? > > > /var/log/audit/audit.log says something like... > > type=USER_AVC msg=audit(1139940939.476:4123): user pid=1528 uid=81 > auid=4294967295 msg='avc: denied { send_msg } for > msgtype=method_call interface=org.freedesktop.DBus member=Hello > dest=org.freedesktop.DBus spid=2994 > scontext=user_u:system_r:unconfined_t > tcontext=system_u:system_r:initrc_t tclass=dbus : exe="?" (sauid=81, > hostname=?, addr=?, terminal=?)' > > Not that I have an idea what that means :) I haven't ever run with > selinux enabled before. Can you file a bug report for this?. You can discuss issues in fedora-selinux list if you need more help. There is a lot of relevant information on SELinux and trouble shooting it available from http://fedoraproject.org/wiki/SELinux -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From jspaleta at gmail.com Tue Feb 14 18:28:57 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 14 Feb 2006 13:28:57 -0500 Subject: Bugzilla dupes attack In-Reply-To: <200602141224.52515.lsomike@futzin.com> References: <43F21632.1000003@fedoraproject.org> <1139940793.17385.181.camel@xpc.home.erwinrol.com> <43F21EE8.3020001@fedoraproject.org> <200602141224.52515.lsomike@futzin.com> Message-ID: <604aa7910602141028t7a76b5ey2255f67bc395c9e@mail.gmail.com> On 2/14/06, Mike Klinke wrote: > Plug "Sundarm" into the initial bugzilla quick search and compare > the results by plugging: > > "Sundaram site:bugzilla.redhat.com" > > into Google. Hey, can you write to google and see if you can get them to release details specifics about their search algorithm so we can re-implement it in open source codebases. Great! thanks! -jef From igorm5 at vip.hr Tue Feb 14 18:29:27 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Tue, 14 Feb 2006 19:29:27 +0100 Subject: Bugzilla dupes attack In-Reply-To: <43F21632.1000003@fedoraproject.org> References: <43F21632.1000003@fedoraproject.org> Message-ID: <43F22187.8000503@vip.hr> Rahul Sundaram wrote: > Hi > Save us a few hours of bugzilla grunt work by not filing two hundred and > seventeen duplicates for a trivial bug. Thanks. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181064 > If anyone has a list of good improvements that can be made to bugzilla > to help is triaging let me know. Jesus Christ, what the heck was that??? I reported the bug only once, and that was on Sunday, not today. I received hundreds of e-mails (!!!) What the heck is going on??? I swear to God I report the Bug only once. I never experience something like that. Thanks and sorry for that embarrassing thing that happened. -- Igor Jagec From gnomeuser at gmail.com Tue Feb 14 18:33:56 2006 From: gnomeuser at gmail.com (David Nielsen) Date: Tue, 14 Feb 2006 19:33:56 +0100 Subject: Bugzilla dupes attack In-Reply-To: <43F21EE8.3020001@fedoraproject.org> References: <43F21632.1000003@fedoraproject.org> <200602141156.31901.lsomike@futzin.com> <43F21C9F.4010904@fedoraproject.org> <1139940793.17385.181.camel@xpc.home.erwinrol.com> <43F21EE8.3020001@fedoraproject.org> Message-ID: <1139942037.2044.7.camel@price.stavtrup-st.dk> tir, 14 02 2006 kl. 23:48 +0530, skrev Rahul Sundaram: > Please be specific enough and provide examples.What is the current > results and what is expected in the search query?. If you are talking > about interface improvements can you provide mockups?. If not what can > you do to help? One of the really good ideas in Malone (Ubuntu' bugtracker) is that the database can be traversed like a directory, I would love to be able to do something similar, like this: + Fedora + Core + cdrecord [All open bugs] [All open bugs upstream] [File bug] So that I don't have to enter search terms to find an application, check the list of bugs of this application and check upstream for known bugs (and if relevant point a pointer bug in FC bugzilla to upstream for tracker blocker purposes, etc.). - David If someone could hook up translations in the same way I would consider them worthy of doughnut rain. -- Obligatory shameless blog plug - the GNOME commentary located at: www.lovesunix.net/blog From sundaram at fedoraproject.org Tue Feb 14 18:39:36 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Feb 2006 00:09:36 +0530 Subject: Bugzilla dupes attack In-Reply-To: <200602141224.52515.lsomike@futzin.com> References: <43F21632.1000003@fedoraproject.org> <1139940793.17385.181.camel@xpc.home.erwinrol.com> <43F21EE8.3020001@fedoraproject.org> <200602141224.52515.lsomike@futzin.com> Message-ID: <43F223E8.4000606@fedoraproject.org> Mike Klinke wrote: >On Tuesday 14 February 2006 12:18, Rahul Sundaram wrote: > > > >>Please be specific enough and provide examples.What is the >>current results and what is expected in the search query?. >> >> > > >Plug "Sundarm" into the initial bugzilla quick search and compare >the results by plugging: > > Typo there. Regardless of that bugzilla doesnt search closed reports by default. Search them by default would waste a lot of time and users generally care only about open bug reports. >"Sundaram site:bugzilla.redhat.com" > >into Google. > > An advanced query on the user name and status set to include closed reports seems to work as expected. http://tinyurl.com/dpyuz -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From sundaram at fedoraproject.org Tue Feb 14 18:44:52 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Feb 2006 00:14:52 +0530 Subject: Bugzilla dupes attack In-Reply-To: <1139942037.2044.7.camel@price.stavtrup-st.dk> References: <43F21632.1000003@fedoraproject.org> <200602141156.31901.lsomike@futzin.com> <43F21C9F.4010904@fedoraproject.org> <1139940793.17385.181.camel@xpc.home.erwinrol.com> <43F21EE8.3020001@fedoraproject.org> <1139942037.2044.7.camel@price.stavtrup-st.dk> Message-ID: <43F22524.30205@fedoraproject.org> David Nielsen wrote: >tir, 14 02 2006 kl. 23:48 +0530, skrev Rahul Sundaram: > > > >>Please be specific enough and provide examples.What is the current >>results and what is expected in the search query?. If you are talking >>about interface improvements can you provide mockups?. If not what can >>you do to help? >> >> > >One of the really good ideas in Malone (Ubuntu' bugtracker) is that the >database can be traversed like a directory, I would love to be able to >do something similar, like this: > >+ Fedora > + Core > + cdrecord [All open bugs] [All open bugs upstream] [File bug] > >So that I don't have to enter search terms to find an application, check >the list of bugs of this application and check upstream for known bugs >(and if relevant point a pointer bug in FC bugzilla to upstream for >tracker blocker purposes, etc.). > >- David > > I discussed Malone with the Ubuntu people over email when someone mentioned this in fedora-test list. It is a proprietary application now and we would rather use a Free and open source application without our infrastructure. I heard there are plans to include XML RPC support in bug buddy so thats a good thing. >If someone could hook up translations in the same way I would consider >them worthy of doughnut rain. > > I would like to keep this discussion specific to improvements that help in triaging bugs for now. There are broader plans to help with integrate translation and rest of the infrastructure but thats not what I am talking about here. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From jarod at wilsonet.com Tue Feb 14 18:46:05 2006 From: jarod at wilsonet.com (Jarod Wilson) Date: Tue, 14 Feb 2006 10:46:05 -0800 Subject: Bugzilla dupes attack In-Reply-To: <43F223E8.4000606@fedoraproject.org> References: <43F21632.1000003@fedoraproject.org> <200602141224.52515.lsomike@futzin.com> <43F223E8.4000606@fedoraproject.org> Message-ID: <200602141046.09040.jarod@wilsonet.com> On Tuesday 14 February 2006 10:39, Rahul Sundaram wrote: > Regardless of that bugzilla doesnt search closed reports by > default. Search them by default would waste a lot of time and users > generally care only about open bug reports. I'm not so sure of that. I *always* search the closed bugs also. You can often find similar issues, or possibly something that was just closed... If the user isn't constantly updating their installed software, they may be running into a bug that was already closed as resolved in a recent release. I know, technically, they should upgrade before reporting a bug, but that isn't always the case, and sometimes the bug is closed as fixed for the next rawhide release, and the user is staying with a release version, so they never see the bug... I think maybe searching open and recently-closed bugs would be a better default (though I dunno what 'recent' should be, exactly. -- Jarod Wilson jarod at wilsonet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cmadams at hiwaay.net Tue Feb 14 18:49:13 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 14 Feb 2006 12:49:13 -0600 Subject: Bugzilla dupes attack In-Reply-To: <43F223E8.4000606@fedoraproject.org> References: <43F21632.1000003@fedoraproject.org> <1139940793.17385.181.camel@xpc.home.erwinrol.com> <43F21EE8.3020001@fedoraproject.org> <200602141224.52515.lsomike@futzin.com> <43F223E8.4000606@fedoraproject.org> Message-ID: <20060214184913.GC776385@hiwaay.net> Once upon a time, Rahul Sundaram said: > Typo there. Regardless of that bugzilla doesnt search closed reports by > default. Search them by default would waste a lot of time and users > generally care only about open bug reports. That's a cause of a number of dupes. Users care about bugs; if a report on the same bug is closed, they won't need to report the same problem (as it is presumably resolved and the closed report will tell the resolution). A convenient shortcut that would be useful for Fedora would be a way to search "current" releases by default (e.g. 4, fc5t2, and devel at the moment). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jspaleta at gmail.com Tue Feb 14 18:50:33 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 14 Feb 2006 13:50:33 -0500 Subject: Bugzilla dupes attack In-Reply-To: <43F223E8.4000606@fedoraproject.org> References: <43F21632.1000003@fedoraproject.org> <1139940793.17385.181.camel@xpc.home.erwinrol.com> <43F21EE8.3020001@fedoraproject.org> <200602141224.52515.lsomike@futzin.com> <43F223E8.4000606@fedoraproject.org> Message-ID: <604aa7910602141050q577b9ea6v120ee7f21ea0d1f6@mail.gmail.com> On 2/14/06, Rahul Sundaram wrote: > Typo there. Regardless of that bugzilla doesnt search closed reports by > default. Search them by default would waste a lot of time and users > generally care only about open bug reports. I don't really know if you can make that "general" claim. I find a lot of users who don't religiously run full system updates, whether it be because of bandwidth or laziness or whatever, wander into #fedora and ask specific questions about specific bugs which are clearly closed and incorporated into some sort of update..even if its a rawhide only fix. And lets face it, somethings which irk users of current releases get closed as resolution rawhide and don't make it into an actual release update. Those closed bugreports still have relevancy even to up-to-date current release systems. On a persona note, I personally don't bother with the default searches anymore when tracking down previously reported bugs when troubleshooting symptoms reported in #fedora. -jef From seandarcy2 at gmail.com Tue Feb 14 18:53:04 2006 From: seandarcy2 at gmail.com (sean) Date: Tue, 14 Feb 2006 13:53:04 -0500 Subject: can anybody install gnome-volume-manager? In-Reply-To: <43F218E7.9020305@city-fan.org> References: <1139902787.28615.15.camel@laurel.intra.city-fan.org> <43F20B13.2020800@city-fan.org> <43F218E7.9020305@city-fan.org> Message-ID: Paul Howarth wrote: > sean wrote: > >> Paul Howarth wrote: >> >>> sean wrote: >>> >>>> Paul Howarth wrote: >>>> >>>>> On Mon, 2006-02-13 at 22:40 -0500, sean wrote: >>>>> >>>>>> on amd64: >>>>>> >>>>>> rpm -Uvh gnome-volume-manager-1.5.11-1.2.x86_64.rpm >>>>>> Preparing... ########################################### [100%] >>>>>> 1:gnome-volume-manager >>>>>> ########################################### [100%] >>>>>> error: unpacking of archive failed on file /usr/bin/magicdev: >>>>>> cpio: rename failed - Operation not permitted >>>>>> >>>>>> I've also rebuilt from the src.rpm. Same result. Looked at the >>>>>> spec file. Nothing odd. >>>>>> >>>>>> Am I missing some magic handshake? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> What's /usr/bin/magicdev on your system? >>>>> >>>>> $ ls -l /usr/bin/magicdev >>>>> >>>>> And what is it in the rpm? >>>>> >>>>> $ rpm -qlpv gnome-volume-manager-1.5.11-1.2.x86_64.rpm | grep >>>>> -F /usr/bin/magicdev >>>>> >>>>> Paul. >>>>> >>>> >>>> ls -l /usr/bin/magicdev >>>> -rw-r--r-- 1 root root 0 Feb 26 2003 /usr/bin/magicdev >>>> >>>> rpm -qlpv gnome-volume-manager-1.5.11-1.2.x86_64.rpm | grep -F >>>> /usr/bin/magicdev >>>> -rwxr-xr-x 1 root root 262 Feb 13 22:32 >>>> /usr/bin/magicdev >>> >>> >>> >>> >>> Curious; it seems to be just a regular file in both cases. This >>> problem usually manifests itself when one is a file and the other is >>> a directory. Can you try removing or renaming /usr/bin/magicdev >>> before installing the RPM? >>> >>> Paul. >>> >> >> Really curious. Look: >> >> [root at amd64-3000 development]# rpm -qif /usr/bin/magicdev >> file /usr/bin/magicdev is not owned by any package >> [root at amd64-3000 development]# rm -f /usr/bin/magicdev >> rm: cannot remove `/usr/bin/magicdev': Operation not permitted >> [root at amd64-3000 development]# chmod 777 /usr/bin/magicdev >> chmod: changing permissions of `/usr/bin/magicdev': Operation not >> permitted >> [root at amd64-3000 development]# mv /usr/bin/magicdev . >> mv: cannot move `/usr/bin/magicdev' to `./magicdev': Operation not >> permitted > > > Maybe it's immutable: > > # lsattr /usr/bin/magicdev > > Paul. > Wow! Who knew? chattr -i worked. Thanks a lot. I'd never heard about immutable, much less figured that out. sean From n0dalus+redhat at gmail.com Tue Feb 14 18:54:19 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Wed, 15 Feb 2006 05:24:19 +1030 Subject: Bugzilla dupes attack In-Reply-To: <43F21632.1000003@fedoraproject.org> References: <43F21632.1000003@fedoraproject.org> Message-ID: <6280325c0602141054p662eae3bm84c8e1687cb06aa0@mail.gmail.com> On 2/15/06, Rahul Sundaram wrote: > > If anyone has a list of good improvements that can be made to bugzilla > to help is triaging let me know. > There is a link at the bottom of a bug search to 'Change several bugs at once.' Unfortunately it doesn't seem to let you mark bugs as dupes -- though it lets you do almost anything else. Adding a feature for this shouldn't be too hard, in case this kind of thing happens in future. I think the biggest improvement that could be made to Red Hat's bugzilla is improving its speed. It takes so long to load every page that you spend a good portion of any triaging time waiting for it to load. If this is because the server isn't fast enough, I think Red Hat needs to consider throwing some more hardware at it -- once you add up the developer time being wasted because it's slowness, it makes sense to spend some money and improve it. It may be slow because of the large page sizes that bugzilla is generating. The large lists of components and versions etc should really be put in an external javascript file; this would allow all pages to load much faster as it could be cached. A non-javascript version should still be available of course. Bugzilla also doesn't seem to use gzip/deflate, it uses chunked encoding which I'm not sure provides any compression. It's not unsual for the pages to exceed 0.5MB in size, and on a 512k connection that really adds up. Other improvements that could be made is to make our bugzilla more like Gnome's. They have their bugzilla modifications available at cvs.gnome.org. n0dalus. From jspaleta at gmail.com Tue Feb 14 18:56:08 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 14 Feb 2006 13:56:08 -0500 Subject: can anybody install gnome-volume-manager? In-Reply-To: References: <1139902787.28615.15.camel@laurel.intra.city-fan.org> <43F20B13.2020800@city-fan.org> <43F218E7.9020305@city-fan.org> Message-ID: <604aa7910602141056t3ccde543qb669d0fd5eb92ecd@mail.gmail.com> On 2/14/06, sean wrote: > Wow! Who knew? > > chattr -i worked. > > Thanks a lot. I'd never heard about immutable, much less > figured that out. the deeper question is... how did it get marked immutable? -jef From lsomike at futzin.com Tue Feb 14 18:57:32 2006 From: lsomike at futzin.com (Mike Klinke) Date: Tue, 14 Feb 2006 12:57:32 -0600 Subject: Bugzilla dupes attack In-Reply-To: <43F223E8.4000606@fedoraproject.org> References: <43F21632.1000003@fedoraproject.org> <200602141224.52515.lsomike@futzin.com> <43F223E8.4000606@fedoraproject.org> Message-ID: <200602141257.32693.lsomike@futzin.com> On Tuesday 14 February 2006 12:39, RS wrote: > bugzilla doesnt search closed reports by > default. Search them by default would waste a lot of time and > users generally care only about open bug reports. It's not clear to the casual user, there's no "advanced" search entry point on the page ( bugzilla.redhat.com ) and you're sure to get dups of bugs that have already been closed. It seem's more productive to check all bugs by default and select open bugs by choice if dups are something you're trying to avoid. > Search them by default would waste a lot of time and > users generally care only about open bug reports. I suggest that "users" really care to know first if what they've found has been seen by anyone else and then second whether it's been fixed. Regards, Mike Klinke From sundaram at fedoraproject.org Tue Feb 14 19:00:42 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Feb 2006 00:30:42 +0530 Subject: Bugzilla dupes attack In-Reply-To: <604aa7910602141050q577b9ea6v120ee7f21ea0d1f6@mail.gmail.com> References: <43F21632.1000003@fedoraproject.org> <1139940793.17385.181.camel@xpc.home.erwinrol.com> <43F21EE8.3020001@fedoraproject.org> <200602141224.52515.lsomike@futzin.com> <43F223E8.4000606@fedoraproject.org> <604aa7910602141050q577b9ea6v120ee7f21ea0d1f6@mail.gmail.com> Message-ID: <43F228DA.8040805@fedoraproject.org> Jeff Spaleta wrote: >On 2/14/06, Rahul Sundaram wrote: > > >>Typo there. Regardless of that bugzilla doesnt search closed reports by >>default. Search them by default would waste a lot of time and users >>generally care only about open bug reports. >> >> > >I don't really know if you can make that "general" claim. > > Thats the claim being made when selecting the default. Do you believe that searching through bugzilla for all the closed bug report makes better sense as the default? >I find a lot of users who don't religiously run full system updates, >whether it be because of bandwidth or laziness or whatever, wander >into #fedora and ask specific questions about specific bugs which are >clearly closed and incorporated into some sort of update..even if its >a rawhide only fix. And lets face it, somethings which irk users of >current releases get closed as resolution rawhide and don't make it >into an actual release update. Those closed bugreports still have >relevancy even to up-to-date current release systems. > > Then reopen it asking for an update against the current release or file another bug report asking for a fix or better yet provide a patch depending on the severity of the bug. Some of the fixes would of course be only available in the next release. I dont see this as improvement that affects triaging. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From overholt at redhat.com Tue Feb 14 19:02:45 2006 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 14 Feb 2006 14:02:45 -0500 Subject: Bugzilla dupes attack In-Reply-To: <6280325c0602141054p662eae3bm84c8e1687cb06aa0@mail.gmail.com> References: <43F21632.1000003@fedoraproject.org> <6280325c0602141054p662eae3bm84c8e1687cb06aa0@mail.gmail.com> Message-ID: <20060214190245.GB8048@redhat.com> * n0dalus [2006-02-14 13:54]: > I think the biggest improvement that could be made to Red Hat's > bugzilla is improving its speed. Agreed. In semi-related news, work is being done on the Bugzilla plugin for Eclipse. Support was recently added to work with RH bugzilla via XML-RPC. As XML-RPC makes its way into other bugzillas, the upcoming bug creation and modification functionality will be extended to those as well. Also, I did a bit of work to make it work as a standalone appliation (pseudo-RCP for the Eclipse folks out there). Interaction suggestions are always appreciated. Just file an RFE or something in bugzilla against eclipse-bugzilla. Andrew From n0dalus+redhat at gmail.com Tue Feb 14 19:14:09 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Wed, 15 Feb 2006 05:44:09 +1030 Subject: Bugzilla dupes attack In-Reply-To: <43F228DA.8040805@fedoraproject.org> References: <43F21632.1000003@fedoraproject.org> <1139940793.17385.181.camel@xpc.home.erwinrol.com> <43F21EE8.3020001@fedoraproject.org> <200602141224.52515.lsomike@futzin.com> <43F223E8.4000606@fedoraproject.org> <604aa7910602141050q577b9ea6v120ee7f21ea0d1f6@mail.gmail.com> <43F228DA.8040805@fedoraproject.org> Message-ID: <6280325c0602141114h651b63et7d0b0fc64b083117@mail.gmail.com> On 2/15/06, Rahul Sundaram wrote: > > [...] I dont see this as improvement that affects triaging. > I think that any bugzilla improvements resulting in improved bug reports or reduced numbers of duplicates should in turn increase triaging efficiency. n0dalus. From sundaram at fedoraproject.org Tue Feb 14 19:23:25 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Feb 2006 00:53:25 +0530 Subject: Bugzilla dupes attack In-Reply-To: <6280325c0602141114h651b63et7d0b0fc64b083117@mail.gmail.com> References: <43F21632.1000003@fedoraproject.org> <1139940793.17385.181.camel@xpc.home.erwinrol.com> <43F21EE8.3020001@fedoraproject.org> <200602141224.52515.lsomike@futzin.com> <43F223E8.4000606@fedoraproject.org> <604aa7910602141050q577b9ea6v120ee7f21ea0d1f6@mail.gmail.com> <43F228DA.8040805@fedoraproject.org> <6280325c0602141114h651b63et7d0b0fc64b083117@mail.gmail.com> Message-ID: <43F22E2D.5060604@fedoraproject.org> n0dalus wrote: >On 2/15/06, Rahul Sundaram wrote: > > >>[...] I dont see this as improvement that affects triaging. >> >> >> > >I think that any bugzilla improvements resulting in improved bug >reports or reduced numbers of duplicates should in turn increase >triaging efficiency. > > > If you have a bugzilla RFE that directly affects triaging instead of a generic enhancement like improving search speed, file in against bugzilla itself as a component in http://bugzilla.redhat.com and let me know the report number. Thanks. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From toshio at tiki-lounge.com Tue Feb 14 19:26:13 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 14 Feb 2006 11:26:13 -0800 Subject: Bugzilla dupes attack In-Reply-To: <43F228DA.8040805@fedoraproject.org> References: <43F21632.1000003@fedoraproject.org> <1139940793.17385.181.camel@xpc.home.erwinrol.com> <43F21EE8.3020001@fedoraproject.org> <200602141224.52515.lsomike@futzin.com> <43F223E8.4000606@fedoraproject.org> <604aa7910602141050q577b9ea6v120ee7f21ea0d1f6@mail.gmail.com> <43F228DA.8040805@fedoraproject.org> Message-ID: <1139945173.3330.30.camel@localhost> On Wed, 2006-02-15 at 00:30 +0530, Rahul Sundaram wrote: > Jeff Spaleta wrote: > > >On 2/14/06, Rahul Sundaram wrote: > > > > > >>Typo there. Regardless of that bugzilla doesnt search closed reports by > >>default. Search them by default would waste a lot of time and users > >>generally care only about open bug reports. > >> > >> > > > >I don't really know if you can make that "general" claim. > > > > > Thats the claim being made when selecting the default. Do you believe > that searching through bugzilla for all the closed bug report makes > better sense as the default? > Yes. Or at least, best-when-searching-for-dupes a convenient entry point to which is part of the submit new bug process. Perhaps most useful is: search for open or closed bugs in Fedora Release I'm running or later (FC3, FC4, devel), (FC4, devel), or (devel) currently (although that requires asking for the FC-release before running the query.) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Tue Feb 14 19:32:05 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Feb 2006 01:02:05 +0530 Subject: Bugzilla dupes attack In-Reply-To: <1139945173.3330.30.camel@localhost> References: <43F21632.1000003@fedoraproject.org> <1139940793.17385.181.camel@xpc.home.erwinrol.com> <43F21EE8.3020001@fedoraproject.org> <200602141224.52515.lsomike@futzin.com> <43F223E8.4000606@fedoraproject.org> <604aa7910602141050q577b9ea6v120ee7f21ea0d1f6@mail.gmail.com> <43F228DA.8040805@fedoraproject.org> <1139945173.3330.30.camel@localhost> Message-ID: <43F23035.2000404@fedoraproject.org> Hi >> >> >> >Yes. > >Or at least, best-when-searching-for-dupes a convenient entry point to >which is part of the submit new bug process. Perhaps most useful is: >search for open or closed bugs in Fedora Release I'm running or later >(FC3, FC4, devel), (FC4, devel), or (devel) currently (although that >requires asking for the FC-release before running the query.) > Can you file a RFE against bugzilla and let me know the report number? -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From jspaleta at gmail.com Tue Feb 14 19:42:28 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 14 Feb 2006 14:42:28 -0500 Subject: Bugzilla dupes attack In-Reply-To: <43F228DA.8040805@fedoraproject.org> References: <43F21632.1000003@fedoraproject.org> <1139940793.17385.181.camel@xpc.home.erwinrol.com> <43F21EE8.3020001@fedoraproject.org> <200602141224.52515.lsomike@futzin.com> <43F223E8.4000606@fedoraproject.org> <604aa7910602141050q577b9ea6v120ee7f21ea0d1f6@mail.gmail.com> <43F228DA.8040805@fedoraproject.org> Message-ID: <604aa7910602141142o66a849e0nb13719408e476a2@mail.gmail.com> On 2/14/06, Rahul Sundaram wrote: > Thats the claim being made when selecting the default. Do you > believe that searching through bugzilla for all the closed bug report > makes better sense as the default? Appropriately organized.... yes. More than lumping all open rhel+fedora+fedora-legacy into the same single query box. Which is more relevant to a user of fedora's current release... rhel bugs or closed fc4 bugs? The single search box for all of the "product" definitions in bugzilla makes ill-fitting assumptions about relevancy in an effort to shoehorn all the products in the same single text box. I think perhaps making it easy to add closed reports for a specific release into an updated results list without having to go through the full advanced query interface would make it a smoother process. Make it easier to refine a query inside the result list page. Make it clear that the default query box searches all open bugs in all "product" release get list A of open tickets for rhel+fedora Core+fedora legacy+whatever Then in ui that hangs around list A make it easy to narrow the search to a specific product "rhel OR fedora OR whatever" and add closed bugs back in into the result...without invoking the full advanced search UI. > Then reopen it asking for an update against the current release or file > another bug report asking for a fix or better yet provide a patch > depending on the severity of the bug. Some of the fixes would of > course be only available in the next release. You misunderstand... how do users reopen a bug they don't know exists because its not in the default search? Users using the default search box who are searching for already reported bugs filed against the release they are using which have been closed rawhide are unfortunately mislead to believe that the bug has not been reported yet.. unless they take the extra effort to do the non-default query and include rawhide resolved bugs. Nor do they see any subsequent dupes of that bug which get filed and marked as dupes. Having multiple "normal" users refile the same bug again and again to be marked as a duplicate again again against the rawhide resolved bug they don't see in the default search ui is just a waste of time. > I dont see this as improvement > that affects triaging. Do you want to limit the duplicate filing of already closed bugs or do you want to encourage the filing of duplicates to already closed bugs? I understand the value of duplicate bug reports for open bugs, as tool to guage the extent of occurance of hard to reproduce or hardware specific problems. But I am unsure of the value of setting up a default search bug which delibrately hides rawhide resolved bugs and encourages people to refile bugs which have already been marked rawhide resolution. -jef From jspaleta at gmail.com Tue Feb 14 19:49:29 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 14 Feb 2006 14:49:29 -0500 Subject: Bugzilla dupes attack In-Reply-To: <1139945173.3330.30.camel@localhost> References: <43F21632.1000003@fedoraproject.org> <1139940793.17385.181.camel@xpc.home.erwinrol.com> <43F21EE8.3020001@fedoraproject.org> <200602141224.52515.lsomike@futzin.com> <43F223E8.4000606@fedoraproject.org> <604aa7910602141050q577b9ea6v120ee7f21ea0d1f6@mail.gmail.com> <43F228DA.8040805@fedoraproject.org> <1139945173.3330.30.camel@localhost> Message-ID: <604aa7910602141149m28843c5cxa59acade5e6a3160@mail.gmail.com> On 2/14/06, Toshio Kuratomi wrote: > Or at least, best-when-searching-for-dupes a convenient entry point to > which is part of the submit new bug process. Perhaps most useful is: > search for open or closed bugs in Fedora Release I'm running or later > (FC3, FC4, devel), (FC4, devel), or (devel) currently (although that > requires asking for the FC-release before running the query.) I would propose having seperate entry pages for the different distribution products. Do we really need to drive rhel and fedora users to the same default bugzilla search page? Can we embed different default bugzilla search box into product specific "portal" sites and drive users into bugzilla through that embedded search box? Cam we embed a bugzilla query box into wikipages at fedoraproject.org? If we can you can easily mock up "portal" default queries for Extras and Core and Legacy and Docs by giving each part of the Fedora space its own "portal" wikipage with an embedded custom bugzilla query box. -jef From rowan at stasis.org Tue Feb 14 20:19:30 2006 From: rowan at stasis.org (Rowan Kerr) Date: Tue, 14 Feb 2006 15:19:30 -0500 Subject: gnome-power-manager quits unexpectedly In-Reply-To: <43F220B1.1070201@fedoraproject.org> References: <4b3752c70602122012n73a21d1bic65b6c926247f8db@mail.gmail.com> <15e53e180602130204r3ad5c492i@mail.gmail.com> <43F0EE07.1070501@stasis.org> <1139918767.3848.3.camel@localhost.localdomain> <43F21F8C.5010905@stasis.org> <43F220B1.1070201@fedoraproject.org> Message-ID: <43F23B52.7000005@stasis.org> Rahul Sundaram wrote: > Can you file a bug report for this?. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181522 From toshio at tiki-lounge.com Tue Feb 14 20:20:23 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 14 Feb 2006 12:20:23 -0800 Subject: Bugzilla dupes attack In-Reply-To: <604aa7910602141142o66a849e0nb13719408e476a2@mail.gmail.com> References: <43F21632.1000003@fedoraproject.org> <1139940793.17385.181.camel@xpc.home.erwinrol.com> <43F21EE8.3020001@fedoraproject.org> <200602141224.52515.lsomike@futzin.com> <43F223E8.4000606@fedoraproject.org> <604aa7910602141050q577b9ea6v120ee7f21ea0d1f6@mail.gmail.com> <43F228DA.8040805@fedoraproject.org> <604aa7910602141142o66a849e0nb13719408e476a2@mail.gmail.com> Message-ID: <1139948424.3330.40.camel@localhost> Regarding the duplicate filings in this particular case, this RFE seems to address the same problem:: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169746 On Tue, 2006-02-14 at 14:42 -0500, Jeff Spaleta wrote: > On 2/14/06, Rahul Sundaram wrote: > > Thats the claim being made when selecting the default. Do you > > believe that searching through bugzilla for all the closed bug report > > makes better sense as the default? > > Appropriately organized.... yes. I've filed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181524 Please add anything you think is relevant, Jef. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lsomike at futzin.com Tue Feb 14 20:50:37 2006 From: lsomike at futzin.com (Mike Klinke) Date: Tue, 14 Feb 2006 14:50:37 -0600 Subject: Bugzilla dupes attack In-Reply-To: <604aa7910602141028t7a76b5ey2255f67bc395c9e@mail.gmail.com> References: <43F21632.1000003@fedoraproject.org> <200602141224.52515.lsomike@futzin.com> <604aa7910602141028t7a76b5ey2255f67bc395c9e@mail.gmail.com> Message-ID: <200602141450.37734.lsomike@futzin.com> On Tuesday 14 February 2006 12:28, JS wrote: > Hey, can you write to google and see if you can get them to > release details specifics about their search algorithm so we can > re-implement it in open source codebases. ?Great! thanks! Not sure I understand your suggestion. Are you suggesting that the bugzilla search/interface cannot be improved? I think we have already identified a difference in that bugzilla is geared toward insuring duplicates are filed a due to the bugzilla search engine's default configuration. Regards, Mike Klinke From jspaleta at gmail.com Tue Feb 14 21:30:54 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 14 Feb 2006 16:30:54 -0500 Subject: Bugzilla dupes attack In-Reply-To: <200602141450.37734.lsomike@futzin.com> References: <43F21632.1000003@fedoraproject.org> <200602141224.52515.lsomike@futzin.com> <604aa7910602141028t7a76b5ey2255f67bc395c9e@mail.gmail.com> <200602141450.37734.lsomike@futzin.com> Message-ID: <604aa7910602141330w715636b1kfd96de05e7c1370e@mail.gmail.com> On 2/14/06, Mike Klinke wrote: > Not sure I understand your suggestion. Are you suggesting that the > bugzilla search/interface cannot be improved? No.. of course it can be improved.. I'm suggesting that your example does nothing but state the obvious fact that google has a better search algorithm than bugzilla... and the statement of that obvious fact doesn't help us identify how the bugzilla search can be made better specifically. I'm suggesting that there is very little to be learned from the specific comparison to google. I'm saying that since we are incapable of examining the details of how google search works, there is very little to be gleamed from looking at example output from google at all. The magic in the google search is the search algorithm which produces the results. And its exactly that piece of magic which we don't have access to to examine and reuse. Are you really suggesting that we blindly reverse-engineer the google search algorithm and apply it to bugzilla? -jef"breaking news! google..which basis its whole business model on being an search service..has a great proprietary search algorthim..film at 11"spaleta From rodd at clarkson.id.au Tue Feb 14 21:45:59 2006 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 15 Feb 2006 08:45:59 +1100 Subject: GDM In-Reply-To: <1139925058.7788.2.camel@zero.sr.unh.edu> References: <1139857556.2578.3.camel@beast.rexursive.com> <1139860070.2587.4.camel@halflap> <1139861771.16457.2.camel@intrepid> <1139865227.16457.7.camel@intrepid> <003301c630e4$412ef130$0301a8c0@miketc.com> <1139925058.7788.2.camel@zero.sr.unh.edu> Message-ID: <1139953559.2566.4.camel@localhost.localdomain> On Tue, 2006-02-14 at 08:50 -0500, Thomas J. Baker wrote: > On Mon, 2006-02-13 at 16:36 -0500, Jon Nettleton wrote: > > > > > > On 2/13/06, Mike Chambers wrote: > > ----- Original Message ----- > > From: "Thomas J. Baker" > > To: "Development discussions related to Fedora Core" > > > > Sent: Monday, February 13, 2006 3:13 PM > > Subject: Re: GDM > > > > > > > > It doesn't appear my problems are related to gdm. Even at > > runlevel 3, > > > startx bombs out too. The biggest suck is that there don't > > seem to be > > > any error messages anywhere... > > > > I am experiencing the same problem as you are, even in run > > level 3. If you > > try to run gdmsetup, I get an Gtk-Warning error. I hope that > > whoever fixes > > this > > one, would hopefully post a working copy of the rpm somewhere > > (people.redhat.com server would work) until it hits rawhide. > > > > Thanks, > > > > Mike Chambers > > Madisonville, KY > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > This problem appears to be two fold. I fixed /etc/gdm/custom.conf, > > but still could not log in to an X session. I had to move my .fonts > > directory to .fonts-bak and then gnome-session stopped crashing. I > > haven't had time to debug it, or file a bug yet. Maybe later > > tonight. > > > > Jon > > > > I still had the same problem after todays update. I removed the > fonts.cache\* files in my .fonts directory and now everything works > again. Did you happen to keep those files so someone can have a look why they were causing problems? Might be nice if someone else has the same problem if they could keep these files (move them, instead of remove them). r. -- "It's a fine line between denial and faith. It's much better on my side" From lsomike at futzin.com Tue Feb 14 21:56:27 2006 From: lsomike at futzin.com (Mike Klinke) Date: Tue, 14 Feb 2006 15:56:27 -0600 Subject: Bugzilla dupes attack In-Reply-To: <604aa7910602141330w715636b1kfd96de05e7c1370e@mail.gmail.com> References: <43F21632.1000003@fedoraproject.org> <200602141450.37734.lsomike@futzin.com> <604aa7910602141330w715636b1kfd96de05e7c1370e@mail.gmail.com> Message-ID: <200602141556.27548.lsomike@futzin.com> On Tuesday 14 February 2006 15:30, Jeff Spaleta wrote: > No.. of course it can be improved.. I'm suggesting that your > example does nothing but state the obvious fact that google has a > better search algorithm than bugzilla... and the statement of > that obvious fact doesn't help us identify how the bugzilla > search can be made better specifically. Because of the comparison Rahul noted that the difference was that bugzilla defaults to looking at closed bugs only while Google looks at everything it can find at the site. If the comparison weren't made we'd probably have missed that. It has little to do with Google's search algorithms and more to do with bugzilla's default settings. Regards, Mike Klinke From sundaram at fedoraproject.org Tue Feb 14 22:05:00 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Feb 2006 03:35:00 +0530 Subject: Bugzilla prioritised improvements list Message-ID: <43F2540C.80203@fedoraproject.org> Hi If anyone needs add to the list, kindly file a RFE against bugzilla itself in http://bugzilla.redhat.com and reply to this mail with the report link retaining the CC list. We could take a look at http://mail.gnome.org/archives/desktop-devel-list/2005-December/msg00057.html and http://bugzilla.gnome.org for other ideas. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=79625 ? Use milestones instead of tracking bugs. (policy change) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168000 - Bugs with NEEDINFO should be auto closed after 3 weeks with a comment https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169746 -Dupe detection. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181524 - Make searching for duplicates search closed bugs as well https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=91306 - Private field for setting developer priority https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=111799 - Is "Red Hat Raw Hide" product obsolete? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=151781 - "Add me to CC list" as default https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=54231 - Ability to append comments via Email https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166174 - Better name for "MODIFIED" status https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118070 - Using Bugzilla as a repository for release notes feedback... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=92088 - default to "auto-detect" in the create attachments screen https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164763 -? "steps to reproduce" field should not be mandatory if enhancement is selected. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137034 - Need an owner per release/component https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154357 - Kill the spam spiders on Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132004 - QA contact was removed instead of my email added to cc: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137433 - "Add bug to my list" for "This bug is not in your list" https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=79568 - ? Time stamps say "UTC", but are really in Eastern -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From sundaram at fedoraproject.org Tue Feb 14 22:11:44 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Feb 2006 03:41:44 +0530 Subject: Bugzilla dupes attack In-Reply-To: <200602141556.27548.lsomike@futzin.com> References: <43F21632.1000003@fedoraproject.org> <200602141450.37734.lsomike@futzin.com> <604aa7910602141330w715636b1kfd96de05e7c1370e@mail.gmail.com> <200602141556.27548.lsomike@futzin.com> Message-ID: <43F255A0.5040406@fedoraproject.org> Mike Klinke wrote: >On Tuesday 14 February 2006 15:30, Jeff Spaleta wrote: > > > >>No.. of course it can be improved.. I'm suggesting that your >>example does nothing but state the obvious fact that google has a >>better search algorithm than bugzilla... and the statement of >>that obvious fact doesn't help us identify how the bugzilla >>search can be made better specifically. >> >> > >Because of the comparison Rahul noted that the difference was that >bugzilla defaults to looking at closed bugs only while Google looks >at everything it can find at the site. > > I said bugzilla only looks at open reports by default. Not closed ones. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From lsomike at futzin.com Tue Feb 14 22:21:06 2006 From: lsomike at futzin.com (Mike Klinke) Date: Tue, 14 Feb 2006 16:21:06 -0600 Subject: Bugzilla dupes attack In-Reply-To: <43F255A0.5040406@fedoraproject.org> References: <43F21632.1000003@fedoraproject.org> <200602141556.27548.lsomike@futzin.com> <43F255A0.5040406@fedoraproject.org> Message-ID: <200602141621.06676.lsomike@futzin.com> On Tuesday 14 February 2006 16:11, RS wrote: > I said bugzilla only looks at open reports by default. Not closed > ones. I saw that after I sent it out but figured either Jeff would understand it or someone would note the flub. Regards, Mike Klinke From dax at gurulabs.com Tue Feb 14 22:37:12 2006 From: dax at gurulabs.com (Dax Kelson) Date: Tue, 14 Feb 2006 15:37:12 -0700 Subject: Bugzilla dupes attack In-Reply-To: <43F223E8.4000606@fedoraproject.org> References: <43F21632.1000003@fedoraproject.org> <1139940793.17385.181.camel@xpc.home.erwinrol.com> <43F21EE8.3020001@fedoraproject.org> <200602141224.52515.lsomike@futzin.com> <43F223E8.4000606@fedoraproject.org> Message-ID: <267-SnapperMsg827D11E1C0180C27@[70.7.239.112]> ...... Original Message ....... On Wed, 15 Feb 2006 00:09:36 +0530 "Rahul Sundaram" wrote: >Mike Klinke wrote: > >>On Tuesday 14 February 2006 12:18, Rahul Sundaram wrote: >> >> >> >>>Please be specific enough and provide examples.What is the >>>current results and what is expected in the search query?. >>> >>> >> >> >>Plug "Sundarm" into the initial bugzilla quick search and compare >>the results by plugging: >> >> >Typo there. Regardless of that bugzilla doesnt search closed reports by >default. Search them by default would waste a lot of time and users >generally care only about open bug reports. I pretty much always search closed reports (if not all the available states). Anything else is non-deterministic. ___ Dax Kelson Sent with my Treo From orion at cora.nwra.com Tue Feb 14 22:44:23 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 14 Feb 2006 15:44:23 -0700 Subject: Today's anaconda refuses to partition my disk In-Reply-To: <20060213164248.GA2978@exeter.boston.redhat.com> References: <20060213164248.GA2978@exeter.boston.redhat.com> Message-ID: Chris Lumens wrote: > > Please file a bug with your kickstart file and whatever error message > you're getting on the screen and I'll look at it. Might be a > pykickstart bug. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181571 From d.jacobfeuerborn at conversis.de Wed Feb 15 00:36:47 2006 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Wed, 15 Feb 2006 01:36:47 +0100 Subject: cron/dbus problem? In-Reply-To: <1139849492.30456.4.camel@remedyz.boston.redhat.com> References: <43F09405.5060206@conversis.de> <1139840337.2801.11.camel@lt16585.campus.dmacc.edu> <43F0A0D5.9050107@conversis.de> <1139849492.30456.4.camel@remedyz.boston.redhat.com> Message-ID: <43F2779F.6000206@conversis.de> John (J5) Palmieri wrote: > On Mon, 2006-02-13 at 16:08 +0100, Dennis Jacobfeuerborn wrote: >> Jeffrey C. Ollie wrote: >>> On Mon, 2006-02-13 at 15:13 +0100, Dennis Jacobfeuerborn wrote: >>>> Does anyone have an idea why the session bus seems to be available from a >>>> regular shell but not from cron? >>> Because the environment variable "DBUS_SESSION_BUS_ADDRESS" is set in a >>> regular shell, but not from cron. >> Shouldn't this be considered a bug? What I was trying to do doesn't seem >> like a weird use case so I believe it should be possible to use DBus from >> cron like that. > > And what if your session isn't running or you are running more than one > session? Which bus does the cron job attach to? Good point. Maybe I have to look into writing a little reminder applet for the panel. Regards, Dennis From dedourek at unb.ca Wed Feb 15 01:26:10 2006 From: dedourek at unb.ca (John DeDourek) Date: Tue, 14 Feb 2006 21:26:10 -0400 Subject: Bugzilla dupes attack In-Reply-To: <6280325c0602141114h651b63et7d0b0fc64b083117@mail.gmail.com> References: <43F21632.1000003@fedoraproject.org> <1139940793.17385.181.camel@xpc.home.erwinrol.com> <43F21EE8.3020001@fedoraproject.org> <200602141224.52515.lsomike@futzin.com> <43F223E8.4000606@fedoraproject.org> <604aa7910602141050q577b9ea6v120ee7f21ea0d1f6@mail.gmail.com> <43F228DA.8040805@fedoraproject.org> <6280325c0602141114h651b63et7d0b0fc64b083117@mail.gmail.com> Message-ID: <43F28332.4080601@unb.ca> n0dalus wrote: >On 2/15/06, Rahul Sundaram wrote: > > >>[...] I dont see this as improvement that affects triaging. >> >> >> > >I think that any bugzilla improvements resulting in improved bug >reports or reduced numbers of duplicates should in turn increase >triaging efficiency. > >n0dalus. > > > A related question from a "newbie". If I think I have a bug in FC(n) and a search finds a remarkably similar bug in FC(n-1), be it OPEN, CLOSED, NEEDINFO_REPORTER, or whatever, filed by someone else, what should be my next step? John D. From toshio at tiki-lounge.com Wed Feb 15 01:43:13 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 14 Feb 2006 17:43:13 -0800 Subject: Bugzilla dupes attack In-Reply-To: <43F28332.4080601@unb.ca> References: <43F21632.1000003@fedoraproject.org> <1139940793.17385.181.camel@xpc.home.erwinrol.com> <43F21EE8.3020001@fedoraproject.org> <200602141224.52515.lsomike@futzin.com> <43F223E8.4000606@fedoraproject.org> <604aa7910602141050q577b9ea6v120ee7f21ea0d1f6@mail.gmail.com> <43F228DA.8040805@fedoraproject.org> <6280325c0602141114h651b63et7d0b0fc64b083117@mail.gmail.com> <43F28332.4080601@unb.ca> Message-ID: <1139967793.3330.65.camel@localhost> On Tue, 2006-02-14 at 21:26 -0400, John DeDourek wrote: > n0dalus wrote: > > >On 2/15/06, Rahul Sundaram wrote: > > > > > >>[...] I dont see this as improvement that affects triaging. > >> > >> > >> > > > >I think that any bugzilla improvements resulting in improved bug > >reports or reduced numbers of duplicates should in turn increase > >triaging efficiency. > > > >n0dalus. > > > > > > > A related question from a "newbie". If I think I have a bug in > FC(n) and a search finds a remarkably similar bug in FC(n-1), be > it OPEN, CLOSED, NEEDINFO_REPORTER, or whatever, filed by someone > else, what should be my next step? Good point. If it's OPEN or NEEDINFO it's probably good to tack on to the bug and say it's still present in FC(n), version x.y-z of the package. Sometimes "remarkably similar" is only in the eyes of the reporter, though... I think Mike Harris has mentioned that he gets X bugs where people with different chipsets but the same symptoms pile onto the same bug report, making the eventual resolution of the bug next to impossible. If it's CLOSED, I'd say that opening a new bug (mentioning the previous bug if you think there's a relationship) is my gut feeling. Someone else may have better reasoning that there's a better way to deal with this though. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sdl.web at gmail.com Wed Feb 15 02:03:51 2006 From: sdl.web at gmail.com (leon) Date: Wed, 15 Feb 2006 02:03:51 +0000 Subject: gnome-power-manager quits unexpectedly References: <4b3752c70602122012n73a21d1bic65b6c926247f8db@mail.gmail.com> <15e53e180602130204r3ad5c492i@mail.gmail.com> <43F0EE07.1070501@stasis.org> <1139918767.3848.3.camel@localhost.localdomain> <43F1CD1B.6070007@fedoraproject.org> Message-ID: Rahul Sundaram writes: | leon wrote: | | >Indeed. But there is no suspend/hibernate options from gnome-power-manager. | > | > | Check the rawhide reports change log. | | gnome-power-manager-2.13.5.0.20060207-2 | | --------------------------------------- | * Mon Feb 13 2006 Ray Strode - 2.13.5.0.20060207-2 | - remove Hibernate and Suspend from menus as part of | panel/g-p-m integration effort | | -- | Rahul | Where to execute Suspend/Hibernate? -- Leon From fcd-cornette at insight.rr.com Wed Feb 15 04:24:14 2006 From: fcd-cornette at insight.rr.com (Jim Cornette) Date: Tue, 14 Feb 2006 23:24:14 -0500 Subject: Bugzilla dupes attack In-Reply-To: <200602141156.31901.lsomike@futzin.com> References: <43F21632.1000003@fedoraproject.org> <200602141156.31901.lsomike@futzin.com> Message-ID: <43F2ACEE.6020605@insight.rr.com> Mike Klinke wrote: > On Tuesday 14 February 2006 11:41, Rahul Sundaram wrote: > > >>Save us a few hours of bugzilla grunt work by not filing two >>hundred and seventeen duplicates for a trivial bug. Thanks. >> >>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181064 >> >>If anyone has a list of good improvements that can be made to >>bugzilla to help is triaging let me know. > > > Over the years the single biggest complaint voiced on these lists is > the poor search results bugzilla provides. If the searches > provided better results perhaps duplcatess wouldn't be so > prevalent. > > Regards, Mike Klinke > I agree with the search feature for bugs. Bug searches could return hits for bugs filed against rawhide with dates related to the bug era (fc5t1,2 or 3) since these should be test release bugs in reality. This would cut down on the duplicate bug filings. Rawhide since yum was adopted does not allow rawhide to be rawhide during test phases. It is the test release update source also. I think having actual update repos for the test releases would eliminate this factor. Bugzilla itself would work better if it would either group all duplicates in some type of directory structure or would merge information from one bug that is a duplicate of another bug into a common report. Another ideal condition would be linking all these similar reports into a common "best of this bug" (Useful data for resolving the bug) for commonly duplicated bug problems. There are some developers which have done something similar for highly duplicated problems and the results were positive. (gcc and mga/intel problem comes to mind) Jim The universe does not have laws -- it has habits, and habits can be broken. From naoki at valuecommerce.com Wed Feb 15 07:12:29 2006 From: naoki at valuecommerce.com (Naoki) Date: Wed, 15 Feb 2006 16:12:29 +0900 Subject: Xen network performance problem during kickstart. Message-ID: <1139987549.21111.68.camel@dragon.sys.intra> Howdy, So the new hypervisor kernel is working fine which is just dandy. And so now I'm testing the host install process. I'm doing network installs (http) and the performance is just awful. A build to a non xen-guest takes about 5 minutes, however from within the domain it is taking over four hours for a cut down (couple of gig) install. If it was doing this on standalone hardware I'd say it looks like a duplex problem killing network performance, however network performance from the main instance (domain-0) is full whack at 10+MB/sec even when doing two xen guest installs at the same time. I am building from a local mirror of the devel tree and a transfer of a large file from there to domain-0 is happening at 1.46MB/sec. So the install should not be taking this long I would suggest unless there is a problem. So, anybody have any tips as to how to diagnose what the problem might be? "xm top" shows network traffic at a very slow rate, ifconfig shows no errors on the vifs. Cheers, -------------- next part -------------- An HTML attachment was scrubbed... URL: From chandan-dutta.chowdhury at hp.com Wed Feb 15 10:18:38 2006 From: chandan-dutta.chowdhury at hp.com (Chowdhury, Chandan Dutta) Date: Wed, 15 Feb 2006 15:48:38 +0530 Subject: (no subject) Message-ID: Hello All, I see the fedora provides yum and dependencies as this (Fedora) http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPM S/sqlite-3.3.3-1.2.src.rpm http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPM S/python-sqlite-1.1.7-1.2.src.rpm http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPM S/yum-2.5.1-5.src.rpm In this set python-sqlite is from the older 1.1 line while the new line is 2.1. Is there any specific reason why we should stay with the older 1.1 version of python-sqlite (API changes or so.) ? I would like to use the latest python-sqlite-2.1.3 version and not sure if all will work fine. I built yum with this (2.1.3) version of python sqlite on ia32 and things seems to work is there a way to run full tests with yum Regards Chandan Dutta Chowdhury From chandan-dutta.chowdhury at hp.com Wed Feb 15 10:48:04 2006 From: chandan-dutta.chowdhury at hp.com (Chowdhury, Chandan Dutta) Date: Wed, 15 Feb 2006 16:18:04 +0530 Subject: Yum python-sqlite and sqlite Message-ID: Sorry, Plz ignore my previous mail (missed the subject) Hello All, I see the fedora provides yum and dependencies as this (Fedora) http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPM S/sqlite-3.3.3-1.2.src.rpm http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPM S/python-sqlite-1.1.7-1.2.src.rpm http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPM S/yum-2.5.1-5.src.rpm In this set python-sqlite is from the older 1.1 line while the new line is 2.1. Is there any specific reason why we should stay with the older 1.1 version of python-sqlite (API changes or so.) ? I would like to use the latest python-sqlite-2.1.3 version and not sure if all will work fine. I built yum with this (2.1.3) version of python sqlite on ia32 and things seems to work is there a way to run full tests with yum Regards Chandan Dutta Chowdhury -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list From gajownik at fedora.pl Wed Feb 15 11:07:44 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Wed, 15 Feb 2006 12:07:44 +0100 Subject: Yum python-sqlite and sqlite In-Reply-To: References: Message-ID: <43F30B80.8040401@fedora.pl> Dnia 02/15/2006 11:50 AM, U?ytkownik Chowdhury, Chandan Dutta napisa?: > Hello All, Hi! > In this set python-sqlite is from the older 1.1 line while the new line > is 2.1. Is there any specific reason why we should stay with the older > 1.1 version of python-sqlite (API changes or so.) ? It would be better to ask this question on yum-devel list ;-) > I would like to use the latest python-sqlite-2.1.3 If you're using Rawhide, just type: yum install python-sqlite2 In FE-4 there is python-sqlite2-2.0.7. sqlite in FC-4 is too old, so I cannot update it to newer version :/ Hope that helps. -- ^_* From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 15 11:13:51 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 15 Feb 2006 12:13:51 +0100 Subject: Header is not complete yum errors today? Message-ID: <20060215121351.194b6717@python2> Hi, While trying to rebuild some packages for FC development today, and trying to update a test system, I keep getting these errors, even after deleting the files from my mirror, re-downloading them from Red Hat, an running "yum clean all" on the clients : [...] Added 151 new packages, deleted 0 old in 2.31 seconds Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Downloading header for openssh-clients to pack into transaction set. openssh-clients-4.3p2-1.i 100% |=========================| 32 kB 00:00 http://ftp.lan/pub/fedora/linux/core/development/i386/Fedora/RPMS/openssh-clients-4.3p2-1.i386.rpm: [Errno -1] Header is not complete. Trying other mirror. Error: failure: Fedora/RPMS/openssh-clients-4.3p2-1.i386.rpm from development: [Errno 256] No more mirrors to try. So... I re-enabled the mirrorlist, and it failed with the same error when trying the Duke mirror, but worked fine with the next : [...] Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Downloading header for openssh-clients to pack into transaction set. openssh-clients-4.3p2-1.i 100% |=========================| 32 kB 00:00 http://ftp.dulug.duke.edu/pub/fedora/linux/core/development/i386/Fedora/RPMS/openssh-clients-4.3p2-1.i386.rpm: [Errno -1] Header is not complete. Trying other mirror. openssh-clients-4.3p2-1.i 100% |=========================| 32 kB 00:00 ---> Package openssh-clients.i386 0:4.3p2-1 set to be updated ---> Downloading header for prelink to pack into transaction set. prelink-0.3.6-3.i386.rpm 100% |=========================| 22 kB 00:00 ---> Package prelink.i386 0:0.3.6-3 set to be updated The first thing that striked me was that both my mirror and the Duke mirror use lighttpd... but switching to use ftp on my local mirror gave me the same error. I've checked the files with rpm -K and they're all fine... I'll now try to re-generate my own metadata. FWIW, my mirror syncs from download2.fedora.redhat.com. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.15-1.1831_FC4 Load : 0.53 0.64 0.49 From chandan-dutta.chowdhury at hp.com Wed Feb 15 11:16:12 2006 From: chandan-dutta.chowdhury at hp.com (Chowdhury, Chandan Dutta) Date: Wed, 15 Feb 2006 16:46:12 +0530 Subject: Yum python-sqlite and sqlite Message-ID: Thanks for the reply, it very well answers the I doubt I had I was not aware of the python-sqlite2 package. In fact I have posted to yum-devel list Thanks and Regards Chandan Dutta Chowdhury -----Original Message----- From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of Dawid Gajownik Sent: Wednesday, February 15, 2006 4:38 PM To: Development discussions related to Fedora Core Subject: Re: Yum python-sqlite and sqlite Dnia 02/15/2006 11:50 AM, U?ytkownik Chowdhury, Chandan Dutta napisa?: > Hello All, Hi! > In this set python-sqlite is from the older 1.1 line while the new > line is 2.1. Is there any specific reason why we should stay with the > older > 1.1 version of python-sqlite (API changes or so.) ? It would be better to ask this question on yum-devel list ;-) > I would like to use the latest python-sqlite-2.1.3 If you're using Rawhide, just type: yum install python-sqlite2 In FE-4 there is python-sqlite2-2.0.7. sqlite in FC-4 is too old, so I cannot update it to newer version :/ Hope that helps. -- ^_* -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list From avi at argo.co.il Wed Feb 15 11:19:00 2006 From: avi at argo.co.il (Avi Kivity) Date: Wed, 15 Feb 2006 13:19:00 +0200 Subject: rpm files changing? Message-ID: <43F30E24.6030107@argo.co.il> I recently switched mirrors, and I noticed existing RPM files are resyncing. Here's an example: [avi at blast rpmdiff]$ diff x y Binary files x/acl-2.2.34-1.2.i386.rpm and y/acl-2.2.34-1.2.i386.rpm differ [avi at blast rpmdiff]$ mkdir x/files y/files [avi at blast rpmdiff]$ (cd x/files; rpm2cpio ../*.rpm | cpio -id) 280 blocks [avi at blast rpmdiff]$ (cd y/files; rpm2cpio ../*.rpm | cpio -id) 280 blocks [avi at blast rpmdiff]$ diff -r x/files y/files/ [avi at blast rpmdiff]$ so, the contents are exactly the same, but the packages have changed. Looking a bit further, one of the RPMs is signed and the other is not. Are the RPMs signed in-place on the exported directory? If so, I suggest that signing them in a staging area and then copying them to the exporting directory would reduce mirror bandwidth and confusion. -- error compiling committee.c: too many arguments to function From gianluca.cecchi at gmail.com Wed Feb 15 13:35:00 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Wed, 15 Feb 2006 14:35:00 +0100 Subject: Update problem Message-ID: <561c252c0602150535v50c3488ev@mail.gmail.com> On Tue, 14 Feb 2006 21:27:40 +0100 Truls Gulbrandsen wrote: > I have the past couple of days tried to update my TC5t2 but it all hangs Just a try; if you run yum update yum does it get updated? In that case, after upgrade of yum retry the "yum update"... HIH, Gianluca From gianluca.cecchi at gmail.com Wed Feb 15 14:02:29 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Wed, 15 Feb 2006 15:02:29 +0100 Subject: Update problem In-Reply-To: <561c252c0602150535v50c3488ev@mail.gmail.com> References: <561c252c0602150535v50c3488ev@mail.gmail.com> Message-ID: <561c252c0602150602h7ce54f56n@mail.gmail.com> sorry wrong mail list selected in reply... Gianluca 2006/2/15, Gianluca Cecchi : > On Tue, 14 Feb 2006 21:27:40 +0100 Truls Gulbrandsen no> wrote: > > > I have the past couple of days tried to update my TC5t2 but it all hangs > > Just a try; if you run > > yum update yum > does it get updated? > In that case, after upgrade of yum retry the "yum update"... > HIH, > Gianluca > From ph18 at cornell.edu Wed Feb 15 14:06:49 2006 From: ph18 at cornell.edu (Paul A Houle) Date: Wed, 15 Feb 2006 09:06:49 -0500 Subject: Bugzilla dupes attack In-Reply-To: <200602141046.09040.jarod@wilsonet.com> References: <43F21632.1000003@fedoraproject.org> <200602141224.52515.lsomike@futzin.com> <43F223E8.4000606@fedoraproject.org> <200602141046.09040.jarod@wilsonet.com> Message-ID: <6.2.1.2.2.20060215085643.023401b0@postoffice6.mail.cornell.edu> At 01:46 PM 2/14/2006, you wrote: >On Tuesday 14 February 2006 10:39, Rahul Sundaram wrote: > > Regardless of that bugzilla doesnt search closed reports by > > default. Search them by default would waste a lot of time and users > > generally care only about open bug reports. > >I'm not so sure of that. I *always* search the closed bugs also. You can >often >find similar issues, or possibly something that was just closed... If the >user isn't constantly updating their installed software, they may be running >into a bug that was already closed as resolved in a recent release. It's a general guideline that the default search request should turn up *everything* that's possibly relevant. Yes, it's bad to get 50 items, 5 of which are relevant, but it's much worse to get 0 items when 7 are relevant... The latter is what you often see on site-specific search engines because people set the defaults too tight; people are so used to getting 0 results when they do a search on a site that they often don't even try search features embedded in a site. As for the problem of open vs. closed bugs, there is a simple answer... (i) Have a display, either on top or on the side, that says something like 13 bugs unassigned 17 bugs assigned 104 bugs resolved ... people can click on the link to be directed to just a list of bugs with the above status. (ii) Make sure that casual (and serious) users can instantly scan the status of a bug with a minimum amount of cognitive effort. (iii) Order the bugs in order of closed status (open first) unless you've got a much more compelling ranking function (suppose you have some indication of how many people are interested in a bug, you might put the popular bug at the top) RH's bugzilla faces a problem that many sites have: multiple populations of users. (1) There's a group of RH employees and serious Fedora contributors who look at bugzilla every day. (2) There's a group of hardcore Fedora enthusiasts who put bugs into bugzilla on a regular basis. (3) There's a group of Fedora enthusiasts who use bugzilla only occasionally, but they've found a problem that concerns them and that they're passionate about getting fixed. Since people of class (1) are in charge of maintaining Bugzilla, they aren't going to have trouble getting their needs met. On the other hand, making it easy for people to join group (3) and move to (2) is critical for the success of the project. It may make sense to make the interface for bugzilla bimodal: have one interface that's designed to be foolproof for the casual user, and another one that's customizable so that people who use Bugzilla continuously don't have their attention distracted by irrelevant stuff (closed bugs) and don't wear out their wrists with excessive pointing and clicking. From sundaram at fedoraproject.org Wed Feb 15 14:11:28 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Feb 2006 19:41:28 +0530 Subject: Bugzilla dupes attack In-Reply-To: <6.2.1.2.2.20060215085643.023401b0@postoffice6.mail.cornell.edu> References: <43F21632.1000003@fedoraproject.org> <200602141224.52515.lsomike@futzin.com> <43F223E8.4000606@fedoraproject.org> <200602141046.09040.jarod@wilsonet.com> <6.2.1.2.2.20060215085643.023401b0@postoffice6.mail.cornell.edu> Message-ID: <43F33690.7070506@fedoraproject.org> Paul A Houle wrote: > At 01:46 PM 2/14/2006, you wrote: > >> On Tuesday 14 February 2006 10:39, Rahul Sundaram wrote: >> > Regardless of that bugzilla doesnt search closed reports by >> > default. Search them by default would waste a lot of time and users >> > generally care only about open bug reports. >> >> I'm not so sure of that. I *always* search the closed bugs also. You >> can often >> find similar issues, or possibly something that was just closed... If >> the >> user isn't constantly updating their installed software, they may be >> running >> into a bug that was already closed as resolved in a recent release. > > > It's a general guideline that the default search request > should turn up *everything* that's possibly relevant. Yes, it's bad > to get 50 items, 5 of which are relevant, but it's much worse to get > 0 items when 7 are relevant... The latter is what you often see on > site-specific search engines because people set the defaults too > tight; people are so used to getting 0 results when they do a search > on a site that they often don't even try search features embedded in a > site. > > As for the problem of open vs. closed bugs, there is a simple > answer... > > (i) Have a display, either on top or on the side, that says > something like > > 13 bugs unassigned > 17 bugs assigned > 104 bugs resolved > ... > > people can click on the link to be directed to just a list of bugs > with the above status. Can you file a RFE against bugzilla and let me know the report number? -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From ph18 at cornell.edu Wed Feb 15 15:09:15 2006 From: ph18 at cornell.edu (Paul A Houle) Date: Wed, 15 Feb 2006 10:09:15 -0500 Subject: Bugzilla dupes attack In-Reply-To: <604aa7910602141330w715636b1kfd96de05e7c1370e@mail.gmail.co m> References: <43F21632.1000003@fedoraproject.org> <200602141224.52515.lsomike@futzin.com> <604aa7910602141028t7a76b5ey2255f67bc395c9e@mail.gmail.com> <200602141450.37734.lsomike@futzin.com> <604aa7910602141330w715636b1kfd96de05e7c1370e@mail.gmail.com> Message-ID: <6.2.1.2.2.20060215094306.02350920@postoffice6.mail.cornell.edu> At 04:30 PM 2/14/2006, Jeff Spaleta wrote: >I'm suggesting that there is very little to be learned from the >specific comparison to google. I'm saying that since we are incapable >of examining the details of how google search works, there is very >little to be gleamed from looking at example output from google at >all. The magic in the google search is the search algorithm which >produces the results. And its exactly that piece of magic which we >don't have access to to examine and reuse. Are you really suggesting >that we blindly reverse-engineer the google search algorithm and apply >it to bugzilla? The magic of Google isn't in the ranking algorithm, it's in the kind and quantity of data that it searches over and the expectations people have of it. The problems of information retrieval depend on the scale of your database. Historically, people have evaluated IR systems based on two things: precision and recall. If you've got a database with 10,000 items, and there is 1 item that matches, there's a lot of risk that that 1 item will be lost if someone doesn't type in the perfect search term. Recall is the issue, so it's important to stem words (working -> work), have a system that's smart about synonyms, etc. Now, if you're searching a database with 10 billion items, there will be 1 million hits for a 1:10000 item. The issue is picking out the best items out of that million items, so there's more stress on precise phrase matching, things like pagerank. Antispam measures are essential, and so is the removal of duplicate documents. Google's trying to do something entirely different from what bugzilla search is trying to do or, say, beagle should do on your desktop. From rowan at stasis.org Wed Feb 15 15:19:29 2006 From: rowan at stasis.org (Rowan Kerr) Date: Wed, 15 Feb 2006 10:19:29 -0500 Subject: gnome-power-manager quits unexpectedly In-Reply-To: <43F23B52.7000005@stasis.org> References: <4b3752c70602122012n73a21d1bic65b6c926247f8db@mail.gmail.com> <15e53e180602130204r3ad5c492i@mail.gmail.com> <43F0EE07.1070501@stasis.org> <1139918767.3848.3.camel@localhost.localdomain> <43F21F8C.5010905@stasis.org> <43F220B1.1070201@fedoraproject.org> <43F23B52.7000005@stasis.org> Message-ID: <43F34681.1090307@stasis.org> Rowan Kerr wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181522 FYI, this was a symptom of a larger HAL daemon issue with SELinux and has been fixed in selinux-policy-2.2.15-1 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181489 From dimi at lattica.com Wed Feb 15 15:19:41 2006 From: dimi at lattica.com (Dimi Paun) Date: Wed, 15 Feb 2006 10:19:41 -0500 Subject: Bugzilla dupes attack References: <43F21632.1000003@fedoraproject.org><200602141224.52515.lsomike@futzin.com><604aa7910602141028t7a76b5ey2255f67bc395c9e@mail.gmail.com><200602141450.37734.lsomike@futzin.com><604aa7910602141330w715636b1kfd96de05e7c1370e@mail.gmail.com> <6.2.1.2.2.20060215094306.02350920@postoffice6.mail.cornell.edu> Message-ID: <088f01c63243$407fe900$b6491b31@td612671> From: "Paul A Houle" > Google's trying to do something entirely different from what > bugzilla search is trying to do or, say, beagle should do on your desktop. Well put. But at the end of the day, the bugzilla search is not as useful as the Google one, at least for our purpose (that is, to try to avoid dupes). Why not just use Google instead? -- Dimi Paun Lattica, Inc. From lamont at gurulabs.com Wed Feb 15 17:03:28 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Wed, 15 Feb 2006 10:03:28 -0700 Subject: Bugzilla dupes attack In-Reply-To: <088f01c63243$407fe900$b6491b31@td612671> References: <43F21632.1000003@fedoraproject.org> <6.2.1.2.2.20060215094306.02350920@postoffice6.mail.cornell.edu> <088f01c63243$407fe900$b6491b31@td612671> Message-ID: <200602151003.32997.lamont@gurulabs.com> On Wednesday 15 February 2006 08:19am, Dimi Paun wrote: > From: "Paul A Houle" > > > Google's trying to do something entirely different from what > > bugzilla search is trying to do or, say, beagle should do on your > > desktop. > > Well put. But at the end of the day, the bugzilla search is not > as useful as the Google one, at least for our purpose (that is, > to try to avoid dupes). Why not just use Google instead? Might I suggest: s/instead/also/ After all, how hard is it to add a Google search button to the "Zarro Bogos Found" screen? Not hard at all. So, if I search for a bug in Bugzilla and find squat, I can just thumb the Google switch and see if it gives me anything. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Wed Feb 15 17:13:47 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 15 Feb 2006 22:43:47 +0530 Subject: Bugzilla dupes attack In-Reply-To: <200602151003.32997.lamont@gurulabs.com> References: <43F21632.1000003@fedoraproject.org> <6.2.1.2.2.20060215094306.02350920@postoffice6.mail.cornell.edu> <088f01c63243$407fe900$b6491b31@td612671> <200602151003.32997.lamont@gurulabs.com> Message-ID: <43F3614B.50007@fedoraproject.org> Hi >Might I suggest: s/instead/also/ > >After all, how hard is it to add a Google search button to the "Zarro Bogos >Found" screen? Not hard at all. So, if I search for a bug in Bugzilla and >find squat, I can just thumb the Google switch and see if it gives me >anything. > > You know the drill. File a RFE and pass on the link. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 15 18:31:36 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 15 Feb 2006 19:31:36 +0100 Subject: Automatic module loading for DV camera support Message-ID: <20060215193136.5b9e982f@python2> Hi, The only outstanding issue I see to finally get DV (Digital Video) capture working right out of the box on Fedora is having the proper modules being loaded when a camera is connected (through firewire). There is a bit more detail in this bug report : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172105 What would the solution be? Add something like this to modprobe.conf : alias char-major-171-* video1394 (or just raw1394, which seems sufficient) Or maybe now in a file inside modprobe.d belonging to some DV package? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.15-1.1831_FC4 Load : 4.17 3.90 2.39 From buildsys at redhat.com Wed Feb 15 18:38:09 2006 From: buildsys at redhat.com (Build System) Date: Wed, 15 Feb 2006 13:38:09 -0500 Subject: rawhide report: 20060215 changes Message-ID: <200602151838.k1FIc98M021302@porkchop.devel.redhat.com> Updated Packages: binutils-2.16.91.0.6-1 ---------------------- * Tue Feb 14 2006 Jakub Jelinek 2.16.91.0.6-1 - update to 2.16.91.0.6 - fix ppc64 --gc-sections - disassembler fixes for x86_64 cr/debug regs - fix linker search order for DT_NEEDED libs * Mon Jan 02 2006 Jakub Jelinek 2.16.91.0.5-1 - update to 2.16.91.0.5 - don't error about .toc1 references to discarded sectiosn on ppc64 (#175944) * Wed Dec 14 2005 Jakub Jelinek 2.16.91.0.3-2 - put .gnu.linkonce.d.rel.ro.* sections into relro region compat-db-4.2.52-4 ------------------ * Tue Feb 14 2006 Jindrich Novy 4.2.52-4 - clarify pointer usage in db_load.c (#110697) gawk-3.1.5-6.2 -------------- * Tue Feb 14 2006 Karel Zak 3.1.5-6.2 - new version of the gawk-3.1.5-wconcat.patch patch gcc-4.1.0-0.27 -------------- * Tue Feb 14 2006 Alexandre Oliva 4.1.0-0.27 - merge fix by Zdenek Dvorak for regression introduced by patch for PR tree-optimization/26209 * Tue Feb 14 2006 Jakub Jelinek 4.1.0-0.26 - update from gcc-4_1-branch (-r110903:110978) - PRs fortran/20861, fortran/20871, fortran/25059, fortran/25070, fortran/25083, fortran/25088, fortran/25103, fortran/26038, fortran/26074, inline-asm/16194, libfortran/24685, libfortran/25425, target/26141, tree-optimization/26258 - ABI change - revert to GCC 3.3 and earlier behaviour of zero sized bitfields in packed structs (Michael Matz, PR middle-end/22275) - fix valarrays vs. non-POD (Paolo Carlini, Gabriel Dos Reis, PR libstdc++/25626) - fix C++ duplicate declspec diagnostics (Volker Reichelt, PR c++/26151) - fix dominance ICE (Zdenek Dvorak, PR tree-optimization/26209) - add some new Intel {,e,x}mmintrin.h intrinsics (H.J. Lu) - speedup bitset<>::_M_copy_to_string (Paolo Carlini) - fix tree_expr_nonzero_p (Jeff Law) - fix TRUTH_XOR_EXPR handling in VRP (Jeff Law) kudzu-1.2.29-1 -------------- * Tue Feb 14 2006 Bill Nottingham - 1.2.29-1 - silence! mkinitrd-5.0.25-1 ----------------- * Tue Feb 14 2006 Peter Jones - 5.0.25-1 - rework hotplug control fds (#181515) * Tue Feb 14 2006 Peter Jones - 5.0.24-1 - use the right nash-dm command to get the device list - check if a subdevice has the same partition table, not if it starts at the right place (fixes partition comparison on !mirror devices) Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15-4.i686 requires kernel = 0:2.6.15-1.1941_FC5 GFS-kernel - 2.6.15-4.i686 requires /lib/modules/2.6.15-1.1941_FC5 GFS-kernel-smp - 2.6.15-4.i686 requires kernel-smp = 0:2.6.15-1.1941_FC5 GFS-kernel-smp - 2.6.15-4.i686 requires /lib/modules/2.6.15-1.1941_FC5smp cman-kernel - 2.6.15.0-20051219.162641.FC5.11.4.i686 requires kernel = 0:2.6.15-1.1941_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.4.i686 requires /lib/modules/2.6.15-1.1941_FC5 cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.4.i686 requires kernel-smp = 0:2.6.15-1.1941_FC5 cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.4.i686 requires /lib/modules/2.6.15-1.1941_FC5smp dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.3.i686 requires kernel = 0:2.6.15-1.1941_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.3.i686 requires /lib/modules/2.6.15-1.1941_FC5 dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.3.i686 requires kernel-smp = 0:2.6.15-1.1941_FC5 dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.3.i686 requires /lib/modules/2.6.15-1.1941_FC5smp gnbd-kernel - 2.6.15-3.i686 requires kernel = 0:2.6.15-1.1941_FC5 gnbd-kernel - 2.6.15-3.i686 requires /lib/modules/2.6.15-1.1941_FC5 gnbd-kernel-smp - 2.6.15-3.i686 requires kernel-smp = 0:2.6.15-1.1941_FC5 gnbd-kernel-smp - 2.6.15-3.i686 requires /lib/modules/2.6.15-1.1941_FC5smp Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs vconfig - 1.9-1.1.ia64 requires libc.so.6 vconfig - 1.9-1.1.ia64 requires libc.so.6(GLIBC_2.0) Broken deps for ppc ---------------------------------------------------------- ccs-devel - 1.0.3-0.2.ppc requires ccs = 0:1.0.3-0.2 gulm - 1.0.0-2.ppc requires ccs Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 magma-plugins - 1.0.3-1.FC5.ppc64 requires libgulm.so.1()(64bit) vconfig - 1.9-1.1.ppc64 requires libc.so.6 vconfig - 1.9-1.1.ppc64 requires libc.so.6(GLIBC_2.0) Broken deps for s390 ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 Broken deps for s390x ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15-4.x86_64 requires kernel = 0:2.6.15-1.1941_FC5 GFS-kernel - 2.6.15-4.x86_64 requires /lib/modules/2.6.15-1.1941_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.4.x86_64 requires kernel = 0:2.6.15-1.1941_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.4.x86_64 requires /lib/modules/2.6.15-1.1941_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.3.x86_64 requires kernel = 0:2.6.15-1.1941_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.3.x86_64 requires /lib/modules/2.6.15-1.1941_FC5 gnbd-kernel - 2.6.15-3.x86_64 requires kernel = 0:2.6.15-1.1941_FC5 gnbd-kernel - 2.6.15-3.x86_64 requires /lib/modules/2.6.15-1.1941_FC5 From lamont at gurulabs.com Wed Feb 15 19:13:49 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Wed, 15 Feb 2006 12:13:49 -0700 Subject: Bugzilla dupes attack In-Reply-To: <43F3614B.50007@fedoraproject.org> References: <43F21632.1000003@fedoraproject.org> <200602151003.32997.lamont@gurulabs.com> <43F3614B.50007@fedoraproject.org> Message-ID: <200602151213.53802.lamont@gurulabs.com> On Wednesday 15 February 2006 10:13am, Rahul Sundaram wrote: > Hi > > >Might I suggest: s/instead/also/ > > > >After all, how hard is it to add a Google search button to the "Zarro > > Bogos Found" screen? Not hard at all. So, if I search for a bug in > > Bugzilla and find squat, I can just thumb the Google switch and see if it > > gives me anything. > > You know the drill. File a RFE and pass on the link. Done: [ https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181661 ] -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Wed Feb 15 19:31:04 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 16 Feb 2006 01:01:04 +0530 Subject: Bugzilla dupes attack In-Reply-To: <200602151213.53802.lamont@gurulabs.com> References: <43F21632.1000003@fedoraproject.org> <200602151003.32997.lamont@gurulabs.com> <43F3614B.50007@fedoraproject.org> <200602151213.53802.lamont@gurulabs.com> Message-ID: <43F38178.6030909@fedoraproject.org> Lamont R. Peterson wrote: >On Wednesday 15 February 2006 10:13am, Rahul Sundaram wrote: > > >>Hi >> >> >> >>>Might I suggest: s/instead/also/ >>> >>>After all, how hard is it to add a Google search button to the "Zarro >>>Bogos Found" screen? Not hard at all. So, if I search for a bug in >>>Bugzilla and find squat, I can just thumb the Google switch and see if it >>>gives me anything. >>> >>> >>You know the drill. File a RFE and pass on the link. >> >> > >Done: [ https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181661 ] > > Thank you. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From rc040203 at freenet.de Wed Feb 15 20:47:25 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 15 Feb 2006 21:47:25 +0100 Subject: rawhide report: 20060215 changes In-Reply-To: <200602151838.k1FIc98M021302@porkchop.devel.redhat.com> References: <200602151838.k1FIc98M021302@porkchop.devel.redhat.com> Message-ID: <1140036445.11538.84.camel@mccallum.corsepiu.local> > gcc-4.1.0-0.27 > -------------- > * Tue Feb 14 2006 Jakub Jelinek 4.1.0-0.26 > - update from gcc-4_1-branch (-r110903:110978) > - PRs fortran/20861, fortran/20871, fortran/25059, fortran/25070, > fortran/25083, fortran/25088, fortran/25103, fortran/26038, > fortran/26074, inline-asm/16194, libfortran/24685, > libfortran/25425, target/26141, tree-optimization/26258 > - ABI change - revert to GCC 3.3 and earlier behaviour of > zero sized bitfields in packed structs (Michael Matz, PR middle-end/22275) Do I read this correctly - ABI change? The whole FC5 mass rebuilds were in vain? Ralf From jakub at redhat.com Wed Feb 15 20:50:52 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 15 Feb 2006 15:50:52 -0500 Subject: rawhide report: 20060215 changes In-Reply-To: <1140036445.11538.84.camel@mccallum.corsepiu.local> References: <200602151838.k1FIc98M021302@porkchop.devel.redhat.com> <1140036445.11538.84.camel@mccallum.corsepiu.local> Message-ID: <20060215205051.GA24295@devserv.devel.redhat.com> On Wed, Feb 15, 2006 at 09:47:25PM +0100, Ralf Corsepius wrote: > > gcc-4.1.0-0.27 > > -------------- > > > * Tue Feb 14 2006 Jakub Jelinek 4.1.0-0.26 > > - update from gcc-4_1-branch (-r110903:110978) > > - PRs fortran/20861, fortran/20871, fortran/25059, fortran/25070, > > fortran/25083, fortran/25088, fortran/25103, fortran/26038, > > fortran/26074, inline-asm/16194, libfortran/24685, > > libfortran/25425, target/26141, tree-optimization/26258 > > - ABI change - revert to GCC 3.3 and earlier behaviour of > > zero sized bitfields in packed structs (Michael Matz, PR middle-end/22275) > > Do I read this correctly - ABI change? Yes. > The whole FC5 mass rebuilds were in vain? No, packed structures containing zero width bitfields are extremely rare. And if something really cared about the exact layout of those structures, it wouldn't rely on this, as GCC < 3.4 behavior differed from 3.4/4.0. Jakub From fedora at adslpipe.co.uk Wed Feb 15 20:57:36 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Wed, 15 Feb 2006 20:57:36 +0000 Subject: corrupt RPM header in rawhide? Message-ID: <43F395C0.7070703@adslpipe.co.uk> just synch'ed up my local mirror and went to yum update from it ---> Downloading header for librsvg2 to pack into transaction set. librsvg2-2.13.93-1.x86_64 100% |=========================| 12 kB 00:00 http://shuttle/fc5/x86_64/Fedora/RPMS/librsvg2-2.13.93-1.x86_64.rpm: [Errno -1] Header is not complete. I deleted the file from my mirror and downloaded a fresh copy direct from http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/Fedora/RPMS/librsvg2-2.13.93-1.x86_64.rpm still same thing, anyone else? I didn't see this file in the last couple of day's worth of changelogs ... From avi at argo.co.il Wed Feb 15 21:05:12 2006 From: avi at argo.co.il (Avi Kivity) Date: Wed, 15 Feb 2006 23:05:12 +0200 Subject: corrupt RPM header in rawhide? In-Reply-To: <43F395C0.7070703@adslpipe.co.uk> References: <43F395C0.7070703@adslpipe.co.uk> Message-ID: <43F39788.4030904@argo.co.il> Andy Burns wrote: > just synch'ed up my local mirror and went to yum update from it > > ---> Downloading header for librsvg2 to pack into transaction set. > librsvg2-2.13.93-1.x86_64 100% |=========================| 12 kB > 00:00 > http://shuttle/fc5/x86_64/Fedora/RPMS/librsvg2-2.13.93-1.x86_64.rpm: > [Errno -1] Header is not complete. > > I deleted the file from my mirror and downloaded a fresh copy direct from > > http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/Fedora/RPMS/librsvg2-2.13.93-1.x86_64.rpm > > > still same thing, anyone else? I didn't see this file in the last > couple of day's worth of changelogs ... > > > seems like the packages are signed in-place on the download server, so if your mirror picked it up at the right time... -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. From rc040203 at freenet.de Wed Feb 15 21:08:09 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 15 Feb 2006 22:08:09 +0100 Subject: rawhide report: 20060215 changes In-Reply-To: <20060215205051.GA24295@devserv.devel.redhat.com> References: <200602151838.k1FIc98M021302@porkchop.devel.redhat.com> <1140036445.11538.84.camel@mccallum.corsepiu.local> <20060215205051.GA24295@devserv.devel.redhat.com> Message-ID: <1140037689.11538.90.camel@mccallum.corsepiu.local> On Wed, 2006-02-15 at 15:50 -0500, Jakub Jelinek wrote: > On Wed, Feb 15, 2006 at 09:47:25PM +0100, Ralf Corsepius wrote: > > > gcc-4.1.0-0.27 > > > -------------- > > > > > * Tue Feb 14 2006 Jakub Jelinek 4.1.0-0.26 > > > - update from gcc-4_1-branch (-r110903:110978) > > > - PRs fortran/20861, fortran/20871, fortran/25059, fortran/25070, > > > fortran/25083, fortran/25088, fortran/25103, fortran/26038, > > > fortran/26074, inline-asm/16194, libfortran/24685, > > > libfortran/25425, target/26141, tree-optimization/26258 > > > - ABI change - revert to GCC 3.3 and earlier behaviour of > > > zero sized bitfields in packed structs (Michael Matz, PR middle-end/22275) > > > > Do I read this correctly - ABI change? > > Yes. > > > The whole FC5 mass rebuilds were in vain? > > No, packed structures containing zero width bitfields are extremely rare. OK, nevertheless, something to keep an eye on. Should somebody find such a struct in a core part of a central library (very low level packages (kernel, glibc, drivers) or GUI-toolskits seem likely candidates, to me), .... > And if something really cared about the exact layout of those structures, > it wouldn't rely on this, as GCC < 3.4 behavior differed from 3.4/4.0. This shouldn't matter here, because the rebuild was initiated by the GCC 4.0->4.1 transition. Ralf From tmus at tmus.dk Wed Feb 15 21:22:53 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 15 Feb 2006 22:22:53 +0100 Subject: Bugzilla prioritised improvements list In-Reply-To: <43F2540C.80203@fedoraproject.org> References: <43F2540C.80203@fedoraproject.org> Message-ID: Not sure where put put it, but i find that one of the reasons bz is hard to find duplicates in, are because the "devel" version under "fedora core" product, for example, is not about bugs in current rawhide, as expected, but has bugs that dates back to the "old days" making "devel" a wierd moving target and test-x almost outdated on release, since most testers will be using rawhide anyways. Perhaps there could be some refinement useful here??? /Thomas From seandarcy2 at gmail.com Wed Feb 15 23:51:52 2006 From: seandarcy2 at gmail.com (sean) Date: Wed, 15 Feb 2006 18:51:52 -0500 Subject: Automatic module loading for DV camera support In-Reply-To: <20060215193136.5b9e982f@python2> References: <20060215193136.5b9e982f@python2> Message-ID: Matthias Saou wrote: > Hi, > > The only outstanding issue I see to finally get DV (Digital Video) capture > working right out of the box on Fedora is having the proper modules being > loaded when a camera is connected (through firewire). There is a bit more > detail in this bug report : > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172105 > > What would the solution be? Add something like this to modprobe.conf : > > alias char-major-171-* video1394 (or just raw1394, which seems sufficient) > > Or maybe now in a file inside modprobe.d belonging to some DV package? > > Matthias > FWIW, look at: http://www.kinodv.org/dcforum/dcforum?az=show_topic&forum=101&topic_id=1890&mesg_id=1890&listing_type=search sean From katzj at redhat.com Thu Feb 16 00:00:56 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 15 Feb 2006 19:00:56 -0500 Subject: Automatic module loading for DV camera support In-Reply-To: <20060215193136.5b9e982f@python2> References: <20060215193136.5b9e982f@python2> Message-ID: <1140048056.15496.0.camel@orodruin.boston.redhat.com> On Wed, 2006-02-15 at 19:31 +0100, Matthias Saou wrote: > The only outstanding issue I see to finally get DV (Digital Video) capture > working right out of the box on Fedora is having the proper modules being > loaded when a camera is connected (through firewire). There is a bit more > detail in this bug report : > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172105 > > What would the solution be? Add something like this to modprobe.conf : > > alias char-major-171-* video1394 (or just raw1394, which seems sufficient) > > Or maybe now in a file inside modprobe.d belonging to some DV package? Or just file a bug against module-init-tools to get the alias added to modprobe.conf.dist Jeremy From rmo at sunnmore.net Thu Feb 16 01:21:00 2006 From: rmo at sunnmore.net (Roy-Magne Mo) Date: Thu, 16 Feb 2006 02:21:00 +0100 Subject: Xen network performance problem during kickstart. In-Reply-To: <1139987549.21111.68.camel@dragon.sys.intra> References: <1139987549.21111.68.camel@dragon.sys.intra> Message-ID: <1140052865.2302.64.camel@host-81-191-138-132.bluecom.no> on den 15.02.2006 klokka 16:12 (+0900) skreiv Naoki: > Howdy, > > So the new hypervisor kernel is working fine which is just dandy. And > so now I'm testing the host install process. I'm doing network > installs (http) and the performance is just awful. A build to a non > xen-guest takes about 5 minutes, however from within the domain it is > taking over four hours for a cut down (couple of gig) install. Network performance seems good here, even looks like the network performance has improved quite a bit for XEN-guest now. I'm seeing 6.3Mbyte/s with large files over HTTP now. The XEN guest has been installed on a separate logical volume. From naoki at valuecommerce.com Thu Feb 16 03:26:19 2006 From: naoki at valuecommerce.com (Naoki) Date: Thu, 16 Feb 2006 12:26:19 +0900 Subject: Xen network performance problem during kickstart. In-Reply-To: <1140052865.2302.64.camel@host-81-191-138-132.bluecom.no> References: <1139987549.21111.68.camel@dragon.sys.intra> <1140052865.2302.64.camel@host-81-191-138-132.bluecom.no> Message-ID: <1140060379.21111.145.camel@dragon.sys.intra> Hmm, I had two installs running and they were so slow I left the office and on my return I find this : This guy was only at 23% complete : Traceback (most recent call last): File "/usr/bin/anaconda", line 1210, in ? handleException(dispatch, intf, sys.exc_info()) File "/usr/lib/anaconda/exception.py", line 380, in handleException win.run() File "/usr/lib/anaconda/text.py", line 154, in run self.text, self.buttons) File "/usr/lib/python2.4/site-packages/snack.py", line 765, in ButtonChoiceWindow t = TextboxReflowed(width, text, maxHeight = screen.height - 12) File "/usr/lib/python2.4/site-packages/snack.py", line 218, in __init__ (newtext, width, height) = reflow(text, width, flexDown, flexUp) File "/usr/lib/python2.4/site-packages/snack.py", line 472, in reflow return _snack.reflow(text, width, flexDown, flexUp) TypeError: argument 1 must be string without null bytes, not str install exited abnormally sending termination signals...done sending kill signals...done And this from the other which was 72% complete : Traceback (most recent call last): File "/usr/bin/anaconda", line 1210, in ? handleException(dispatch, intf, sys.exc_info()) File "/usr/lib/anaconda/exception.py", line 380, in handleException win.run() File "/usr/lib/anaconda/text.py", line 154, in run self.text, self.buttons) File "/usr/lib/python2.4/site-packages/snack.py", line 765, in ButtonChoiceWindow t = TextboxReflowed(width, text, maxHeight = screen.height - 12) File "/usr/lib/python2.4/site-packages/snack.py", line 218, in __init__ (newtext, width, height) = reflow(text, width, flexDown, flexUp) File "/usr/lib/python2.4/site-packages/snack.py", line 472, in reflow return _snack.reflow(text, width, flexDown, flexUp) TypeError: argument 1 must be string without null bytes, not str install exited abnormally sending termination signals...done sending kill signals...done I'd hazard a guess it was an anaconda problem ? From rmo at sunnmore.net Thu Feb 16 03:52:46 2006 From: rmo at sunnmore.net (Roy-Magne Mo) Date: Thu, 16 Feb 2006 04:52:46 +0100 Subject: Xen network performance problem during kickstart. In-Reply-To: <1140060379.21111.145.camel@dragon.sys.intra> References: <1139987549.21111.68.camel@dragon.sys.intra> <1140052865.2302.64.camel@host-81-191-138-132.bluecom.no> <1140060379.21111.145.camel@dragon.sys.intra> Message-ID: <1140061966.2302.67.camel@host-81-191-138-132.bluecom.no> to den 16.02.2006 klokka 12:26 (+0900) skreiv Naoki: > I'd hazard a guess it was an anaconda problem ? I'm using text-based install, how about trying that? -- Roy-Magne Mo From naoki at valuecommerce.com Thu Feb 16 05:23:38 2006 From: naoki at valuecommerce.com (Naoki) Date: Thu, 16 Feb 2006 14:23:38 +0900 Subject: Xen network performance problem during kickstart. In-Reply-To: <1140061966.2302.67.camel@host-81-191-138-132.bluecom.no> References: <1139987549.21111.68.camel@dragon.sys.intra> <1140052865.2302.64.camel@host-81-191-138-132.bluecom.no> <1140060379.21111.145.camel@dragon.sys.intra> <1140061966.2302.67.camel@host-81-191-138-132.bluecom.no> Message-ID: <1140067419.4651.23.camel@dragon.sys.intra> It is the text based install. I don't think I've ever used graphical and using a mouse is for wimps ;) On Thu, 2006-02-16 at 04:52 +0100, Roy-Magne Mo wrote: > to den 16.02.2006 klokka 12:26 (+0900) skreiv Naoki: > > > I'd hazard a guess it was an anaconda problem ? > > I'm using text-based install, how about trying that? From fedora at camperquake.de Thu Feb 16 08:16:34 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 16 Feb 2006 09:16:34 +0100 Subject: Bugzilla prioritised improvements list In-Reply-To: References: <43F2540C.80203@fedoraproject.org> Message-ID: <20060216091634.7f905742@dhcp05.addix.net> Hi. On Wed, 15 Feb 2006 22:22:53 +0100, Thomas M Steenholdt wrote: > Not sure where put put it, but i find that one of the reasons bz is > hard to find duplicates in, are because the "devel" version under > "fedora core" product, for example, is not about bugs in current > rawhide, as expected, but has bugs that dates back to the "old days" I'm sorry? I was under the impression that FC->Devel was the category tracking, well FC devel, which is what rawhide was some years ago. From naoki at valuecommerce.com Thu Feb 16 08:28:54 2006 From: naoki at valuecommerce.com (Naoki) Date: Thu, 16 Feb 2006 17:28:54 +0900 Subject: Xen network performance problem during kickstart. In-Reply-To: <1140060379.21111.145.camel@dragon.sys.intra> References: <1139987549.21111.68.camel@dragon.sys.intra> <1140052865.2302.64.camel@host-81-191-138-132.bluecom.no> <1140060379.21111.145.camel@dragon.sys.intra> Message-ID: <1140078535.4651.84.camel@dragon.sys.intra> Doh! I just tried another install to see it it was reproduced and it is, same error : return _snack.reflow(text, width, flexDown, flexUp) TypeError: argument 1 must be string without null bytes, not str On Thu, 2006-02-16 at 12:26 +0900, Naoki wrote: > Hmm, I had two installs running and they were so slow I left the office > and on my return I find this : > > This guy was only at 23% complete : > > Traceback (most recent call last): File > "/usr/bin/anaconda", line 1210, in ? > > handleException(dispatch, intf, sys.exc_info()) > File > "/usr/lib/anaconda/exception.py", line 380, in handleException > win.run() > > File "/usr/lib/anaconda/text.py", line 154, in run > self.text, self.buttons) > File > "/usr/lib/python2.4/site-packages/snack.py", line 765, in > ButtonChoiceWindow > > t = TextboxReflowed(width, text, maxHeight = screen.height - 12) > File > "/usr/lib/python2.4/site-packages/snack.py", line 218, in __init__ > > (newtext, width, height) = reflow(text, width, flexDown, flexUp) > File > "/usr/lib/python2.4/site-packages/snack.py", line 472, in reflow > > return _snack.reflow(text, width, flexDown, flexUp) > > TypeError: argument 1 must be string without null bytes, not str > install exited > abnormally > > sending termination signals...done > > sending kill signals...done > > > > > > And this from the other which was 72% complete : > > Traceback (most recent call last): > File "/usr/bin/anaconda", line 1210, in ? > handleException(dispatch, intf, sys.exc_info()) > File > "/usr/lib/anaconda/exception.py", line 380, in handleException > win.run() > > File "/usr/lib/anaconda/text.py", line 154, in run > self.text, self.buttons) > File > "/usr/lib/python2.4/site-packages/snack.py", line 765, in > ButtonChoiceWindow > > t = TextboxReflowed(width, text, maxHeight = screen.height - 12) > File > "/usr/lib/python2.4/site-packages/snack.py", line 218, in __init__ > > (newtext, width, height) = reflow(text, width, flexDown, flexUp) > File > "/usr/lib/python2.4/site-packages/snack.py", line 472, in reflow > > return _snack.reflow(text, width, flexDown, flexUp) > > TypeError: argument 1 must be string without null bytes, not str > install exited > abnormally > > sending termination signals...done > > sending kill signals...done > > > > I'd hazard a guess it was an anaconda problem ? From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 16 13:24:02 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 16 Feb 2006 14:24:02 +0100 Subject: Automatic module loading for DV camera support In-Reply-To: <1140048056.15496.0.camel@orodruin.boston.redhat.com> References: <20060215193136.5b9e982f@python2> <1140048056.15496.0.camel@orodruin.boston.redhat.com> Message-ID: <20060216142402.086eb079@python2> Jeremy Katz wrote : > On Wed, 2006-02-15 at 19:31 +0100, Matthias Saou wrote: > > The only outstanding issue I see to finally get DV (Digital Video) capture > > working right out of the box on Fedora is having the proper modules being > > loaded when a camera is connected (through firewire). There is a bit more > > detail in this bug report : > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172105 > > > > What would the solution be? Add something like this to modprobe.conf : > > > > alias char-major-171-* video1394 (or just raw1394, which seems sufficient) > > > > Or maybe now in a file inside modprobe.d belonging to some DV package? > > Or just file a bug against module-init-tools to get the alias added to > modprobe.conf.dist OK : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181768 Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.15-1.1831_FC4 Load : 0.39 0.36 0.66 From mharris at mharris.ca Thu Feb 16 16:29:42 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Thu, 16 Feb 2006 11:29:42 -0500 Subject: Request for volunteers: xfs config corrupted during upgrade - bug 179006 Message-ID: <43F4A876.4010309@mharris.ca> A couple people have reported a bug in which xfs fails to start properly due to the config file being corrupted upon install. Something is causing one of the config file lines later in the file (default-point-size) to be inserted into the list of font directories, which of course breaks xfs startup. My assumption is that chkfontpath is causing this, however if that turns out to be true, it will be quite odd for this to just start happening all of a sudden, as chkfontpath hasn't really changed substantially in a long time. Another possibility is that rpm post script processing in some package (or packages) are modifying the xfs config and causing this to happen, or causing it to be in a state that chkfontpath never would have encountered before. Unfortunately, there is no 100% reproduceable test case yet in order to easily debug the problem, so I would like everyone who experiences this problem to CC themselves on the master bug that is tracking this issue, and add any information that might help to narrow the problem down, as this bug is potentially one of the nastiest X bugs on the FC5Blocker list, since a non-starting font server means a non starting X server. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179006 I'm going to continue trying to trigger the issue locally, but any assistance in narrowing down a reproduceable test case and/or diagnosing the issue is appreciated. You can also find me on #fedora-x on freenode. TIA -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Thu Feb 16 16:30:11 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Thu, 16 Feb 2006 11:30:11 -0500 Subject: Request for volunteers: xfs config corrupted during upgrade - bug 179006 Message-ID: <43F4A893.9060701@mharris.ca> A couple people have reported a bug in which xfs fails to start properly due to the config file being corrupted upon install. Something is causing one of the config file lines later in the file (default-point-size) to be inserted into the list of font directories, which of course breaks xfs startup. My assumption is that chkfontpath is causing this, however if that turns out to be true, it will be quite odd for this to just start happening all of a sudden, as chkfontpath hasn't really changed substantially in a long time. Another possibility is that rpm post script processing in some package (or packages) are modifying the xfs config and causing this to happen, or causing it to be in a state that chkfontpath never would have encountered before. Unfortunately, there is no 100% reproduceable test case yet in order to easily debug the problem, so I would like everyone who experiences this problem to CC themselves on the master bug that is tracking this issue, and add any information that might help to narrow the problem down, as this bug is potentially one of the nastiest X bugs on the FC5Blocker list, since a non-starting font server means a non starting X server. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179006 I'm going to continue trying to trigger the issue locally, but any assistance in narrowing down a reproduceable test case and/or diagnosing the issue is appreciated. You can also find me on #fedora-x on freenode. TIA -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From gnomeuser at gmail.com Thu Feb 16 17:11:26 2006 From: gnomeuser at gmail.com (David Nielsen) Date: Thu, 16 Feb 2006 18:11:26 +0100 Subject: No Rawhide release for 16-02-06 ? Message-ID: <1140109887.2289.3.camel@price.stavtrup-st.dk> I don't see a rawhide report today, did someone mess the buildsystem up? - David -- Obligatory shameless blog plug - the GNOME commentary located at: www.lovesunix.net/blog From rowan at stasis.org Thu Feb 16 17:23:42 2006 From: rowan at stasis.org (Rowan Kerr) Date: Thu, 16 Feb 2006 12:23:42 -0500 Subject: gnome-power-manager quits unexpectedly In-Reply-To: <43F34681.1090307@stasis.org> References: <4b3752c70602122012n73a21d1bic65b6c926247f8db@mail.gmail.com> <15e53e180602130204r3ad5c492i@mail.gmail.com> <43F0EE07.1070501@stasis.org> <1139918767.3848.3.camel@localhost.localdomain> <43F21F8C.5010905@stasis.org> <43F220B1.1070201@fedoraproject.org> <43F23B52.7000005@stasis.org> <43F34681.1090307@stasis.org> Message-ID: <43F4B51E.1000805@stasis.org> Rowan Kerr wrote: > FYI, this was a symptom of a larger HAL daemon issue with SELinux and > has been fixed in selinux-policy-2.2.15-1 > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181489 For some reason, I'm still at selinux-policy-2.2.14-2.. new package hasn't gone into rawhide yet? From dgregor at redhat.com Thu Feb 16 17:32:30 2006 From: dgregor at redhat.com (Dennis Gregorovic) Date: Thu, 16 Feb 2006 12:32:30 -0500 Subject: No Rawhide release for 16-02-06 ? In-Reply-To: <1140109887.2289.3.camel@price.stavtrup-st.dk> References: <1140109887.2289.3.camel@price.stavtrup-st.dk> Message-ID: <1140111150.9261.22.camel@localhost.localdomain> On Thu, 2006-02-16 at 18:11 +0100, David Nielsen wrote: > I don't see a rawhide report today, did someone mess the buildsystem up? Yes, a typos got introduced in some changes yesterday. I restarted the rawhide process and it should be finishing up shortly. Cheers -- Dennis From buildsys at redhat.com Thu Feb 16 17:52:08 2006 From: buildsys at redhat.com (Build System) Date: Thu, 16 Feb 2006 12:52:08 -0500 Subject: rawhide report: 20060216 changes Message-ID: <200602161752.k1GHq8s7031540@porkchop.devel.redhat.com> Updated Packages: GConf2-2.13.5-4 --------------- * Wed Feb 15 2006 Christopher Aillon 2.13.5-4 - Send SIGTERM instead of SIGHUP to gconfd * Mon Feb 13 2006 Jesse Keating 2.13.5-3.2.1 - rebump for build order issues during double-long bump * Fri Feb 10 2006 Jesse Keating 2.13.5-3.2 - bump again for double-long bug on ppc(64) GFS-kernel-2.6.15-5.FC5.4 ------------------------- a2ps-4.13b-49 ------------- * Wed Feb 15 2006 Tim Waugh 4.13b-49 - Use mktemp in scripts. anaconda-10.92.5-1 ------------------ * Tue Feb 14 2006 Jeremy Katz - 10.92.5-1 - Fix traceback in language group selection - No remote save traceback button if not network (clumens) - More fixes for minstg2.img (clumens) - Disable next/back while installing packages (dcantrel) - Bump minimum amounts for install, graphical and early swap - Enable Arabic for text mode (notting) autoconf-2.59-7 --------------- * Wed Feb 15 2006 Karsten Hopp 2.59-7 - XrmInitialize takes no argument (#181340) beagle-0.2.1-6 -------------- * Wed Feb 15 2006 Alexander Larsson 0.2.1-6 - Make all dlls exectuable to correctly pick up dependencies cdrtools-8:2.01.01.0.a03-3 -------------------------- * Wed Feb 15 2006 Harald Hoyer 8:2.01.01.0.a03-3 - rebuilt * Fri Feb 10 2006 Jesse Keating - 8:2.01.01.0.a03-2.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 8:2.01.01.0.a03-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes cman-kernel-2.6.15.0-20051219.162641.FC5.11.7 --------------------------------------------- control-center-1:2.13.92-2 -------------------------- * Wed Feb 15 2006 Matthias Clasen - 2.13.92-2 - Add a missing BuildRequires * Wed Feb 15 2006 Matthias Clasen - 2.13.92-1 - Update to 2.13.92 db4-4.3.29-2 ------------ * Wed Feb 15 2006 Jindrich Novy 4.3.29-2 - don't package /usr/share/doc/images in the main db4 package and move it to db4-devel (#33328) - make db4 LFS capable (#33849) - move db4-devel, db4-tcl, db4-java to Development/Libraries group instead of System Environment/Libraries (#54320) - BuildPrereq -> BuildRequires - don't use RPM_SOURCE_DIR - Obsoletes db3, db2 dhcp-11:3.0.3-22 ---------------- * Tue Feb 14 2006 Jason Vas Dias - 11:3.0.3-22 - fix bug 181482: resolv.conf not updated on RENEW : since dhcp-3.0.1rc12-RHScript.patch: "$new_domain_servers" should have been "$new_domain_name_servers" :-( diskdumputils-1.2.8-3 --------------------- * Tue Feb 14 2006 Dave Anderson - 1.2.8-3 - Updated source package to diskdumputils-1.2.8.tar.gz. * Tue Feb 07 2006 Jesse Keating - 1.0.1-6.3.2 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcc dlm-kernel-2.6.15.0-20051219.162641.FC5.9.7 ------------------------------------------- eclipse-bugzilla-1:0.2.2-2 -------------------------- * Tue Feb 14 2006 Igor Foox 0.2.2-2 - Updated source, removes extraneous debug output. * Tue Feb 14 2006 Igor Foox 0.2.2-1.1 - Bump release. * Tue Feb 14 2006 Igor Foox 0.2.2-1 - Updated to version 0.2.2 which sports working jars included int the plugin. - Changed source file format from -- to -. - Fixed hardcoded versions to variables. - Some formatting fixes. eog-2.13.91-1 ------------- * Wed Feb 15 2006 Matthias Clasen - 2.13.91-1 - Update to 2.13.91 epiphany-1.9.7-1 ---------------- * Mon Feb 13 2006 Christopher Aillon - 1.9.7-1 - Update to 1.9.7 file-roller-2.13.91-1 --------------------- * Wed Feb 15 2006 Matthias Clasen - 2.13.91-1 - Update to 2.13.91 gail-1.8.9-1 ------------ * Mon Feb 13 2006 Matthias Clasen - 1.8.9-1 - Update to 1.8.9 gedit-1:2.13.91-1 ----------------- * Wed Feb 15 2006 Matthias Clasen - 2.13.91-1 - Update to 2.13.91 gkrellm-2.2.7-6 --------------- * Wed Feb 15 2006 Karsten Hopp 2.2.7-6 - fix chkconfig requires gnbd-kernel-2.6.15-5.FC5.7 -------------------------- gnome-applets-1:2.13.4-2 ------------------------ * Wed Feb 15 2006 Matthias Clasen - 2.13.4-2 - Build with --enable-mini-commander gnome-icon-theme-2.14.0-2 ------------------------- * Wed Feb 15 2006 Matthias Clasen 2.14.0-2 - Add small epiphany icon (again!!) gnome-media-2.13.92-1 --------------------- * Wed Feb 15 2006 Matthias Clasen - 2.13.92-1 - Update to 2.13.92 gnome-panel-2.13.91-2 --------------------- * Wed Feb 15 2006 Matthias Clasen - 2.13.91-2 - fix up the gnome-power-manager integration patch * Mon Feb 13 2006 Matthias Clasen - 2.13.91-1 - update to 2.13.91 gnome-screensaver-2.13.91-1 --------------------------- * Wed Feb 15 2006 Matthias Clasen - 2.13.91-1 - Update to 2.13.91 gnome-utils-1:2.13.92-3 ----------------------- * Wed Feb 15 2006 Matthias Clasen - 2.13.92-3 - Fix %post * Wed Feb 15 2006 Matthias Clasen - 2.13.92-2 - Update to gucharmap 1.5.2 - Update to gcalctool 5.7.29 gnupg-1.4.2.1-2 --------------- * Wed Feb 15 2006 Nalin Dahyabhai - 1.4.2.1-2 - rebuild * Wed Feb 15 2006 Nalin Dahyabhai - 1.4.2.1-1 - update to 1.4.2.1 (fixes CVE-2006-0455) gok-1.0.6-1 ----------- * Mon Feb 13 2006 Matthias Clasen - 1.0.6-1 - Update to 1.0.6 gstreamer-0.10.3-3 ------------------ * Tue Feb 14 2006 Rik van Riel - 0.10-3-3 - Obsolete gstreamer-plugins (#181296) * Mon Feb 13 2006 Christopher Aillon - 0.10.3-2 - Rebuild * Fri Feb 10 2006 Christopher Aillon - 0.10.3-1 - Update to 0.10.3 gthumb-2.7.3-1 -------------- * Wed Feb 15 2006 Matthias Clasen - 2.7.3-1 - Update to 2.7.3 - BuildRequire libgphoto2 hplip-0.9.8-4 ------------- * Tue Feb 14 2006 Tim Waugh 0.9.8-4 - Added Obsoletes: hpoj tags back in (bug #181476). initscripts-8.29-1 ------------------ * Tue Feb 14 2006 Peter Jones 8.29-1 - scrub another possible error message from dmraid output kernel-2.6.15-1.1955_FC5 ------------------------ * Wed Feb 15 2006 Stephen Tweedie - Fix module oopses on x86_64 SMP xen dom0 * Wed Feb 15 2006 John W. Linville - Update to current softmac/bcm43xx code. - Set ipw2200 hwcrypto option to 0 to avoid firmware restarts. * Wed Feb 15 2006 Dave Jones - 2.6.16rc3-git4 - Hopefully fix suspend to swap-on-LVM ksh-20060124-2 -------------- * Tue Feb 14 2006 Karsten Hopp 20060124-2 - make it build in chroots (#180561) * Mon Feb 13 2006 Karsten Hopp 20060124-1 - version 20060124 * Fri Feb 10 2006 Jesse Keating - 20050202-5.1 - bump again for double-long bug on ppc(64) kudzu-1.2.30-1 -------------- * Wed Feb 15 2006 Bill Nottingham - 1.2.30-1 - revert changes for video probing classes - some correct devices are 0380 less-394-3 ---------- * Wed Feb 15 2006 Ivana Varekova - 394-3 - add patch for search problem (search did not find string which occurs in a line after '\0') libbonobo-2.13.1-9 ------------------ * Wed Feb 15 2006 Ray Strode 2.13.1-9 - yet another iteration of the shlib patch * Fri Feb 10 2006 Jesse Keating - 2.13.1-8.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 2.13.1-8.1 - rebuilt for new gcc4.1 snapshot and glibc changes libsoup-2.2.7-2 --------------- * Wed Feb 15 2006 Matthias Clasen - 2.2.7-2 - Remove excessive Requires for the -devel package mkinitrd-5.0.26-1 ----------------- * Wed Feb 15 2006 Peter Jones - 5.0.26-1 - fix detection of floppy devices, don't probe them for labels - fix grubby to use the same label scanning code as nash - senseless rewriting of makefiles so that grubby can use nash's .o's, uh, "more easily". nautilus-cd-burner-2.13.91-1 ---------------------------- * Wed Feb 15 2006 Matthias Clasen - 2.13.91-1 - Update to 2.13.91 netpbm-10.31-4 -------------- * Tue Feb 14 2006 Jindrich Novy 10.31-4 - make xwdtopnm work on x86_64 (#181001) notify-daemon-0.3.1-8 --------------------- * Tue Feb 14 2006 Christopher Aillon - 0.3.1-8 - BuildRequires love, for all you lovers out there. nss-3.11-4 ---------- * Wed Feb 15 2006 Kai Engert - 3.11-4 - add --noexecstack when compiling assembler on x86_64 perl-Net-Telnet-3.03-4.3 ------------------------ * Wed Feb 15 2006 Jason Vas Dias - 3.03-4.3 - fix bug 180591: correct URL: tag rhpl-0.182-1 ------------ * Wed Feb 15 2006 David Cantrell - 0.182-1 - setxkbmap corrections for loading X keymaps (#179845) * Thu Dec 22 2005 Jeremy Katz - 0.181-1 - Clean up spacing and use current widgets for exception dialog - add serbian keyboard models (#175611) * Wed Dec 21 2005 Chris Lumens 0.180-1 - Deprecate rhpl.log. rhpxl-0.15-1 ------------ * Wed Feb 15 2006 Bill Nottingham 0.15-1 - order non-vesa videocards before vesa (#176978) rp-pppoe-3.5-31 --------------- * Wed Feb 15 2006 Than Ngo 3.5-31 - apply patch to use mktemp selinux-policy-2.2.15-4 ----------------------- * Wed Feb 15 2006 Dan Walsh 2.2.15-4 - Add router port for zebra - Add imaze port for spamd - Fixes for amanda and java * Tue Feb 14 2006 Dan Walsh 2.2.15-3 - Fix bluetooth handling of usb devices - Fix spamd reading of ~/ - fix nvidia spec * Tue Feb 14 2006 Dan Walsh 2.2.15-1 - Update to upsteam system-config-printer-0.6.151-1 ------------------------------- * Tue Feb 14 2006 Tim Waugh 0.6.151-1 - 0.6.151: - Fixed case-insensitive printer matching (bug #181295). vim-1:6.4.007-1 --------------- * Wed Feb 15 2006 Karsten Hopp 6.4.007-1 - fix vim.csh script (#180429) - patchlevel 7 vixie-cron-4:4.1-52.FC5 ----------------------- * Tue Feb 14 2006 Jason Vas Dias - 4:4.1-52.FC5 - fix bug 181439: enable easier selection of optional 'WITH_*' compilation features Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs vconfig - 1.9-1.1.ia64 requires libc.so.6 vconfig - 1.9-1.1.ia64 requires libc.so.6(GLIBC_2.0) Broken deps for ppc ---------------------------------------------------------- ccs-devel - 1.0.3-0.2.ppc requires ccs = 0:1.0.3-0.2 gulm - 1.0.0-2.ppc requires ccs Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 magma-plugins - 1.0.3-1.FC5.ppc64 requires libgulm.so.1()(64bit) vconfig - 1.9-1.1.ppc64 requires libc.so.6 vconfig - 1.9-1.1.ppc64 requires libc.so.6(GLIBC_2.0) Broken deps for s390 ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 Broken deps for s390x ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) From gilboad at gmail.com Thu Feb 16 18:07:20 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 16 Feb 2006 20:07:20 +0200 Subject: Grub password by default? Message-ID: <1140113240.10693.6.camel@gilboa-work-dev> Hello all, Small question/suggestion: By default, Anaconda doesn't require a grub password. A user must manually select "Use a bootloader password" in-order to set on up. Is there a specific reason for that? Shouldn't Anaconda at-least force the user to acknowledge his selection? ("Are you sure you don't want to setup grub password? Having no password leaves your machine vulnerable to anyone with physical access to your keyboard") Or better yet, why not add an option, within the root password entry window, to use the same password for his grub installation? Gilboa. * I know that having a grub password doesn't mean much if someone has physical access to my machine and a rescue CD. Adding a small message in Anaconda about "Please be advised that adding a BIOS password and preventing CDROM/LAN boot is required to improve the security of your machine" should clear this hurdle. From dax at gurulabs.com Thu Feb 16 18:12:20 2006 From: dax at gurulabs.com (Dax Kelson) Date: Thu, 16 Feb 2006 11:12:20 -0700 Subject: rawhide report: 20060216 changes In-Reply-To: <200602161752.k1GHq8s7031540@porkchop.devel.redhat.com> References: <200602161752.k1GHq8s7031540@porkchop.devel.redhat.com> Message-ID: <1140113540.3476.8.camel@mentorng.gurulabs.com> On Thu, 2006-02-16 at 12:52 -0500, Build System wrote: > kernel-2.6.15-1.1955_FC5 > ------------------------ > * Wed Feb 15 2006 Stephen Tweedie > - Fix module oopses on x86_64 SMP xen dom0 > > * Wed Feb 15 2006 John W. Linville > - Update to current softmac/bcm43xx code. > - Set ipw2200 hwcrypto option to 0 to avoid firmware restarts. FYI, ipw2200 v1.0.11 released yesterday (Feb 15, 2006) has the following changelog entry: "Disable hwcrypto by default as a temporary workaround for the frequent firmware restart problem (thanks to Andreas Happe)" It will be nice when the firmware issues get fixed for lower CPU/power utilization. Dax Kelson Guru Labs From katzj at redhat.com Thu Feb 16 18:13:43 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 16 Feb 2006 13:13:43 -0500 Subject: Grub password by default? In-Reply-To: <1140113240.10693.6.camel@gilboa-work-dev> References: <1140113240.10693.6.camel@gilboa-work-dev> Message-ID: <1140113623.7777.2.camel@bree.local.net> On Thu, 2006-02-16 at 20:07 +0200, Gilboa Davara wrote: > Small question/suggestion: > By default, Anaconda doesn't require a grub password. > A user must manually select "Use a bootloader password" in-order to set > on up. > Is there a specific reason for that? In general, if you have physical access to the machine, you've already lost. We allow setting the boot loader password mainly to help people who have taken other appropriate measures (password protecting the BIOS, ensuring the boot order doesn't boot from removable media, case locks) Jeremy From jaboutboul at speakeasy.net Thu Feb 16 18:21:52 2006 From: jaboutboul at speakeasy.net (Jack Aboutboul) Date: Thu, 16 Feb 2006 13:21:52 -0500 Subject: [Fwd: FUDCon Boston 2006 Call for Papers] Message-ID: <1140114113.1018.54.camel@deepfort> This was sent out last week, but for some reason didn't make it to some of the lists. -------------- next part -------------- An embedded message was scrubbed... From: Jack Aboutboul Subject: FUDCon Boston 2006 Call for Papers Date: Fri, 10 Feb 2006 14:28:26 -0500 Size: 2231 URL: From mharris at mharris.ca Thu Feb 16 18:23:46 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Thu, 16 Feb 2006 13:23:46 -0500 Subject: Grub password by default? In-Reply-To: <1140113240.10693.6.camel@gilboa-work-dev> References: <1140113240.10693.6.camel@gilboa-work-dev> Message-ID: <43F4C332.60704@mharris.ca> Gilboa Davara wrote: > Hello all, > > Small question/suggestion: > By default, Anaconda doesn't require a grub password. > A user must manually select "Use a bootloader password" in-order to set > on up. > Is there a specific reason for that? Yes, if I can pick the machine up physically, and throw it out the window, a grub password wont stop me. Or spill a coffee in the front grille. Yeah, an extremist response... ;o) The idea is that if you have physical access to a machine, you can do absolutely anything to it, regardless of any passwords. A grub password is kindof like the combination lock on the front of a guitar case. It isn't real security. Someone can just steal the entire guitar case if they want to, and pick/break the lock later. Forcing the additional inconvenience of an extra password on everyone, when it buys no real security for the overall general audience, and most people would end up wanting to disable it anyway - is not a good OS default. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From pbrobinson at gmail.com Thu Feb 16 18:38:16 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 16 Feb 2006 18:38:16 +0000 Subject: rawhide report: 20060216 changes In-Reply-To: <200602161752.k1GHq8s7031540@porkchop.devel.redhat.com> References: <200602161752.k1GHq8s7031540@porkchop.devel.redhat.com> Message-ID: <5256d0b0602161038k64dd2616t7ab106356db158be@mail.gmail.com> > Updated Packages: Any chance of getting the new evolution in tomorrows build? pete From saddateh at gmail.com Thu Feb 16 21:36:33 2006 From: saddateh at gmail.com (Sadda Teh) Date: Thu, 16 Feb 2006 16:36:33 -0500 Subject: Yum and SRPMs In-Reply-To: <604aa7910511280856g3f043934g4c7da09e83ed181a@mail.gmail.com> References: <1133079326.2854.1.camel@entropy> <20051128124649.GB29992@jadzia.bu.edu> <1133185654.21208.124.camel@cutter> <6280325c0511280703v2c514df8p63c31ca9cf06def7@mail.gmail.com> <1133190580.6952.0.camel@cutter> <604aa7910511280719l59f4921bja4c15e160cfb4e77@mail.gmail.com> <1133195955.16284.1.camel@weasel.turre.laiskiainen.org> <604aa7910511280856g3f043934g4c7da09e83ed181a@mail.gmail.com> Message-ID: I hate to resurrect this thread, but here goes. A quote from Jesse Keating's most recent blog post: http://jkeating.livejournal.com/15151.html (he's speaking about FC5Test3): "As far as infrastructure goes, this will be the first release using the new unified SRPMs layout that I have been working on. No longer will each arch have its own SRPM CD set. There will be one global source/ directory and within it there will be a SRPMS/ dir and an iso/ dir. The isos being made from the SRPMS/. The SRPMS/ directory will have repodata so that yum can be used to obtain srpms. Also I have removed the debug/ directory from the os directory where it used to live. Now the debug/ is on the same level as os and contains its own repodata and repoview content. I wanted to separate debug packages from core packages so that end users don't have to process the repo info for all the debug packages when they are using yum. So now those of you that need to debug stuff you can enable the debug repo and the srpm repo and be able to do these tasks in an easier way. This also makes it easier for mirrors to elect not to mirror debug or source content. This means we may have to munge the mirror list a bit. For this reason (and possibly others) the debug and source repos are pointed directly to download.fedora.redhat.com. I urge you to check with a local mirror to see if they are mirroring that content and if so change to use that mirror. It will lessen the load on d.f.r.c and hopefully provide packages to you in a faster manner." Does this mean that FC5 will have the capability to do what many people in this thread thought would be a great feature of yum? That is, in FC5 will we now be able to type something along the lines of: yum install metacity.src. And then yum would download that src.rpm and all its dependencies? If so, this is great! Thanks to Jesse and whoever else cooperated to implement this feature. Just this small enhancement, I think, will encourage more developers to play around with the sources of their favorite RPMs. This feature makes it that much easier and more intuitive to get access to the source code. To "preach" a little. The whole idea of free software means having easy access to the source. This is still something which I think no distro has really focused on making an integrated part of the distribution process. Maybe this is a start. I don't know about other packaging systems, but it seems most if not all RPM based distros have two separate worlds. One in which the binary packages exist and another where the source packages exist. Unification of these two worlds is certainly something worth striving for. Any feature that makes it easier for developers to get up and running on the given platform is worth implementing. I guess the next logical progression of this feature would be to have a tool that "disassembles" the SRPMs so that one could cd to some standard directory and be able to fix some bugs in the source and then re-compile the changes (knowing headers, etc. of depended-on libraries are already in place so the build is successful). Probably something like this already exists? My current perception of being able to develop software that's part of the Fedora environment means one needs intimate knowledge of RPM and its various spin off utilities. At least now it seems like a user-friendly tool like yum is going to assist in actually getting the SRPMs onto one's machine. Can Jesse or someone else expand on what this new feature really means if my impression is totally off-base? Good day. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at j2solutions.net Thu Feb 16 21:52:57 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 16 Feb 2006 13:52:57 -0800 Subject: Yum and SRPMs In-Reply-To: References: <1133079326.2854.1.camel@entropy> <20051128124649.GB29992@jadzia.bu.edu> <1133185654.21208.124.camel@cutter> <6280325c0511280703v2c514df8p63c31ca9cf06def7@mail.gmail.com> <1133190580.6952.0.camel@cutter> <604aa7910511280719l59f4921bja4c15e160cfb4e77@mail.gmail.com> <1133195955.16284.1.camel@weasel.turre.laiskiainen.org> <604aa7910511280856g3f043934g4c7da09e83ed181a@mail.gmail.com> Message-ID: <1140126778.2437.23.camel@ender> On Thu, 2006-02-16 at 16:36 -0500, Sadda Teh wrote: > > My current perception of being able to develop software that's part of > the Fedora environment means one needs intimate knowledge of RPM and > its various spin off utilities. At least now it seems like a > user-friendly tool like yum is going to assist in actually getting the > SRPMs onto one's machine. Can Jesse or someone else expand on what > this new feature really means if my impression is totally off-base? I made a small mistake. The unified SRPMS and srpm repodata will be useful for yumdownloader, not yum itself. Yum does not and will not have the ability to grab srpms. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mailinglists at erwinrol.com Thu Feb 16 22:46:08 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Thu, 16 Feb 2006 23:46:08 +0100 Subject: OpenLDAP config update from RPM Message-ID: <1140129969.17385.246.camel@xpc.home.erwinrol.com> Hey all, I am working on Open Xchange for FC5, and was wondering what the "correct" way is to add things to a openldap configuration from "inside" an RPM. For example Open Xchange has a openxchange.schema file with schemas, that i install in /etc/openldap/schema/. Open Xchange also has a file describing the access rights and indexing, those have to be added to the /etc/openldap/slapd.conf file. The question is is there a way to add configuration things to OpenLDAP in the same way as for example with apache (the conf.d directory) ? Or is the only thing i can do installing a README and have the user add those things manually ? TIA, Erwin From rodd at clarkson.id.au Fri Feb 17 00:02:53 2006 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Fri, 17 Feb 2006 11:02:53 +1100 Subject: rawhide report: 20060216 changes In-Reply-To: <200602161752.k1GHq8s7031540@porkchop.devel.redhat.com> References: <200602161752.k1GHq8s7031540@porkchop.devel.redhat.com> Message-ID: <1140134574.3923.21.camel@localhost.localdomain> On Thu, 2006-02-16 at 12:52 -0500, Build System wrote: > Broken deps for ia64 > ---------------------------------------------------------- > rgmanager - 1.9.31-3.ia64 requires ccs > vconfig - 1.9-1.1.ia64 requires libc.so.6 > vconfig - 1.9-1.1.ia64 requires libc.so.6(GLIBC_2.0) > > > > Broken deps for ppc > ---------------------------------------------------------- > ccs-devel - 1.0.3-0.2.ppc requires ccs = 0:1.0.3-0.2 > gulm - 1.0.0-2.ppc requires ccs > > > > Broken deps for ppc64 > ---------------------------------------------------------- > cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= > 0:2.6.11 > dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= > 0:2.6.11 > emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi > gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 > magma-plugins - 1.0.3-1.FC5.ppc64 requires > libgulm.so.1()(64bit) > vconfig - 1.9-1.1.ppc64 requires libc.so.6 > vconfig - 1.9-1.1.ppc64 requires libc.so.6(GLIBC_2.0) > > > > Broken deps for s390 > ---------------------------------------------------------- > rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 > rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 > rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 > > > > Broken deps for s390x > ---------------------------------------------------------- > rhythmbox - 0.8.8-2.s390x requires > libgstcontrol-0.8.so.1()(64bit) > rhythmbox - 0.8.8-2.s390x requires > libgstreamer-0.8.so.1()(64bit) > rhythmbox - 0.8.8-2.s390x requires > libgstgconf-0.8.so.0()(64bit) Where's the broken deps for i686? Well done guys. I don't think I've ever seen so few broken deps. R. -- "It's a fine line between denial and faith. It's much better on my side" From nman64 at n-man.com Fri Feb 17 00:06:24 2006 From: nman64 at n-man.com (Patrick Barnes) Date: Thu, 16 Feb 2006 18:06:24 -0600 Subject: [ANN] Fedora Project Wiki Policy Change Message-ID: <200602161806.29490.nman64@n-man.com> The Fedora Foundation has decided that all Fedora documentation, including the fedoraproject.org wiki, will be licensed under the terms of the Open Publication License 1.0[1] without options. Unfortunately, the Fedora Project does not have copyright privileges over the wiki's existing content. Since we have allowed anyone to edit the wiki without any sort of licensing or copyright assignment, we cannot cover the existing content without the agreement of each contributor. To solve this issue, we have come up with a plan[2]. Our plan will require that all contributors complete the CLA in the Fedora Account System[3] before joining the EditGroup. In order to facilitate our new changes, the EditGroup will be frozen effective immediately and through the weekend. Those of you who are in the EditGroup can continue to make edits during that time, but no new contributors are to be added to the EditGroup during the freeze. Everyone who is in the EditGroup but has not completed the CLA will be removed after this weekend. If you are currently in the EditGroup and have not completed the CLA, please take the time to do so now. This agreement will allow us to license your contributions under the OPL. If you have completed the CLA, but are removed after the weekend, contact someone in the revised EditGroup to add you again. All current EditGroup members who are removed will have their name added to a tracking page[4]. If your name is moved to that list, you will need to complete the CLA and remove yourself from the list to indicate that you agree to having your past contributions licensed under the OPL. DO NOT REMOVE OTHERS from this list. It will be monitored. After an undetermined waiting period, all contributions made by names still on this list will be removed from the wiki. If you would like to learn more about our licensing and other legal terms, visit the Legal page[5] on the wiki. [1] http://fedoraproject.org/wiki/Legal/Licenses/OPL [2] http://fedoraproject.org/wiki/WikiLicenseTalk [3] http://fedoraproject.org/wiki/Infrastructure/AccountSystem [4] http://fedoraproject.org/wiki/UnlicensedGroup [5] http://fedoraproject.org/wiki/Legal -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ -- Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From naoki at valuecommerce.com Fri Feb 17 01:08:08 2006 From: naoki at valuecommerce.com (Naoki) Date: Fri, 17 Feb 2006 10:08:08 +0900 Subject: rawhide report: 20060216 changes In-Reply-To: <1140134574.3923.21.camel@localhost.localdomain> References: <200602161752.k1GHq8s7031540@porkchop.devel.redhat.com> <1140134574.3923.21.camel@localhost.localdomain> Message-ID: <1140138488.4651.126.camel@dragon.sys.intra> :) Funny, that's the first thing I thought this morning, "Hey, why isn't GFS broken anymore?!". Lovely! > > Broken deps for s390x > > ---------------------------------------------------------- > > rhythmbox - 0.8.8-2.s390x requires > > libgstcontrol-0.8.so.1()(64bit) > > rhythmbox - 0.8.8-2.s390x requires > > libgstreamer-0.8.so.1()(64bit) > > rhythmbox - 0.8.8-2.s390x requires > > libgstgconf-0.8.so.0()(64bit) > > Where's the broken deps for i686? > > Well done guys. I don't think I've ever seen so few broken deps. > > > R. From jkeating at redhat.com Fri Feb 17 01:15:16 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 16 Feb 2006 17:15:16 -0800 Subject: rawhide report: 20060216 changes In-Reply-To: <1140138488.4651.126.camel@dragon.sys.intra> References: <200602161752.k1GHq8s7031540@porkchop.devel.redhat.com> <1140134574.3923.21.camel@localhost.localdomain> <1140138488.4651.126.camel@dragon.sys.intra> Message-ID: <1140138916.2437.33.camel@ender> On Fri, 2006-02-17 at 10:08 +0900, Naoki wrote: > :) Funny, that's the first thing I thought this morning, "Hey, why > isn't > GFS broken anymore?!". > > Lovely! rawhide stabilizes during the freeze for a test release. It'll get a bit messy next week (; -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From naoki at valuecommerce.com Fri Feb 17 06:31:42 2006 From: naoki at valuecommerce.com (Naoki) Date: Fri, 17 Feb 2006 15:31:42 +0900 Subject: Xen issues - Was Xen network performance problem during kickstart. In-Reply-To: <1140078535.4651.84.camel@dragon.sys.intra> References: <1139987549.21111.68.camel@dragon.sys.intra> <1140052865.2302.64.camel@host-81-191-138-132.bluecom.no> <1140060379.21111.145.camel@dragon.sys.intra> <1140078535.4651.84.camel@dragon.sys.intra> Message-ID: <1140157902.3229.32.camel@dragon.sys.intra> I've got three problems now seen in my testing. 1) Am seeing this at the start of a guest install. ------------[ cut here ]------------ kernel BUG at include/asm/xor.h:633! invalid opcode: 0000 [#1] SMP Modules linked in: xor raid1 raid0 xennet sr_mod sd_mod scsi_mod cdrom squashfs loop nfs nfs_acl lockd sunrpc vfat fat cramfs CPU: 0 EIP: 0061:[] Not tainted VLI EFLAGS: 00010246 (2.6.15-1.1955_FC5guest) EIP is at xor_sse_2+0x1de/0x1ec [xor] eax: 00000000 ebx: 00000000 ecx: 00000000 edx: caf58000 next screen esi: caf55000 edi: 00000000 ebp: 00000000 esp: caf4fde0 ds: 007b es: 007b ss: 0069 Process loader (pid: 145, threadinfo=caf4e000 task=c04661f0) Stack: <0>00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 d10bc5ac 00000000 d10b9b13 00001000 caf54000 caf57000 caf57000 caf54000 Call Trace: [] do_xor_speed+0x42/0x90 [xor] 2) Ridiculously slow : 4 hours for a guest install of ~500mb. No identifiable host problem. I'm trying to do a network install and the instance running right now is doing less than 1 byte/sec according to "xm top". 3) Install crashes out at random points into install : > > Hmm, I had two installs running and they were so slow I left the office > > and on my return I find this : > > > > This guy was only at 23% complete : > > > > Traceback (most recent call last): File > > "/usr/bin/anaconda", line 1210, in ? > > > > handleException(dispatch, intf, sys.exc_info()) > > File > > "/usr/lib/anaconda/exception.py", line 380, in handleException > > win.run() > > > > File "/usr/lib/anaconda/text.py", line 154, in run > > self.text, self.buttons) > > File > > "/usr/lib/python2.4/site-packages/snack.py", line 765, in > > ButtonChoiceWindow > > > > t = TextboxReflowed(width, text, maxHeight = screen.height - 12) > > File > > "/usr/lib/python2.4/site-packages/snack.py", line 218, in __init__ > > > > (newtext, width, height) = reflow(text, width, flexDown, flexUp) > > File > > "/usr/lib/python2.4/site-packages/snack.py", line 472, in reflow > > > > return _snack.reflow(text, width, flexDown, flexUp) > > > > TypeError: argument 1 must be string without null bytes, not str > > install exited > > abnormally > > > > sending termination signals...done > > > > sending kill signals...done > > > > > > > > > > > > And this from the other which was 72% complete : > > > > Traceback (most recent call last): > > File "/usr/bin/anaconda", line 1210, in ? > > handleException(dispatch, intf, sys.exc_info()) > > File > > "/usr/lib/anaconda/exception.py", line 380, in handleException > > win.run() > > > > File "/usr/lib/anaconda/text.py", line 154, in run > > self.text, self.buttons) > > File > > "/usr/lib/python2.4/site-packages/snack.py", line 765, in > > ButtonChoiceWindow > > > > t = TextboxReflowed(width, text, maxHeight = screen.height - 12) > > File > > "/usr/lib/python2.4/site-packages/snack.py", line 218, in __init__ > > > > (newtext, width, height) = reflow(text, width, flexDown, flexUp) > > File > > "/usr/lib/python2.4/site-packages/snack.py", line 472, in reflow > > > > return _snack.reflow(text, width, flexDown, flexUp) > > > > TypeError: argument 1 must be string without null bytes, not str > > install exited > > abnormally > > > > sending termination signals...done > > > > sending kill signals...done > > If I can get a "me too" I'll file bugzilla's, otherwise I'll keep testing. Any helpful ideas as to where I can look would be appreciated. From avi at argo.co.il Fri Feb 17 07:40:05 2006 From: avi at argo.co.il (Avi Kivity) Date: Fri, 17 Feb 2006 09:40:05 +0200 Subject: OpenLDAP config update from RPM In-Reply-To: <1140129969.17385.246.camel@xpc.home.erwinrol.com> References: <1140129969.17385.246.camel@xpc.home.erwinrol.com> Message-ID: <43F57DD5.2020306@argo.co.il> Erwin Rol wrote: >Hey all, > >I am working on Open Xchange for FC5, and was wondering what the >"correct" way is to add things to a openldap configuration from "inside" >an RPM. > >For example Open Xchange has a openxchange.schema file with schemas, >that i install in /etc/openldap/schema/. Open Xchange also has a file >describing the access rights and indexing, those have to be added to >the /etc/openldap/slapd.conf file. The question is is there a way to add >configuration things to OpenLDAP in the same way as for example with >apache (the conf.d directory) ? Or is the only thing i can do installing >a README and have the user add those things manually ? > > you might have the postinstall script edit the file. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. From buildsys at redhat.com Fri Feb 17 08:19:18 2006 From: buildsys at redhat.com (Build System) Date: Fri, 17 Feb 2006 03:19:18 -0500 Subject: rawhide report: 20060217 changes Message-ID: <200602170819.k1H8JI1T011188@porkchop.devel.redhat.com> Updated Packages: xorg-x11-drivers-7.0-2 ---------------------- * Thu Feb 16 2006 Bill Nottingham - 7.0-2 - uncomment (empty) file list so binary RPMs are built * Fri Feb 10 2006 Jesse Keating - 7.0-1.1 - bump again for double-long bug on ppc(64) * Thu Feb 09 2006 Mike Harris 7.0-1 - Bumped version to 7.0-1 - Updated the driver list to match current rawhide, X11R7.0 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs vconfig - 1.9-1.1.ia64 requires libc.so.6 vconfig - 1.9-1.1.ia64 requires libc.so.6(GLIBC_2.0) Broken deps for ppc ---------------------------------------------------------- gulm-devel - 1.0.0-2.ppc requires gulm = 0:1.0.0-2 magma-plugins - 1.0.3-1.FC5.ppc requires libgulm.so.1 magma-plugins - 1.0.3-1.FC5.ppc requires libdlm_lt.so.1 Broken deps for ppc64 ---------------------------------------------------------- emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gulm-devel - 1.0.0-2.ppc64 requires gulm = 0:1.0.0-2 magma-plugins - 1.0.3-1.FC5.ppc64 requires libdlm_lt.so.1()(64bit) magma-plugins - 1.0.3-1.FC5.ppc64 requires libgulm.so.1()(64bit) vconfig - 1.9-1.1.ppc64 requires libc.so.6 vconfig - 1.9-1.1.ppc64 requires libc.so.6(GLIBC_2.0) Broken deps for s390 ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 Broken deps for s390x ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) From gianluca.cecchi at gmail.com Fri Feb 17 09:49:40 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Fri, 17 Feb 2006 10:49:40 +0100 Subject: gconf multiple versions (was Re: rawhide report: 20060209 changes (part 1/2)) Message-ID: <561c252c0602170149o436a248cu@mail.gmail.com> I also had this problem, and now I have three versions of GConf and one version of GConf2. GConf-1.0.9-18 GConf-1.0.9-18.1 GConf-1.0.9-18.2.1 GConf2-2.13.5-4 I always use "yum localupdate *rpm" to sync the system and sometimes "yum update" to synchronize with extras. I cannot do "rpm -e GConf-1.0.9-18" because I get the same error as below. I have not the system at hanf right now but I presume "yum remove" will provide same results. BTW how are GConf and GConf2 related? From "rpm -qi" of them I have not understood it. Can I for example remove GConf and get only GConf2 installed? It seems that the README files of the two packages are the same.... Thanks in advance, Gianluca On Thu, 9 Feb 2006 07:58:28 -0800 Tom London wrote: >I get this installing today: > > Cleanup : GConf ##################### [351/638] >/sbin/ldconfig: relative path `1' used to build cache >error: %postun(GConf-1.0.9-18.i386) scriptlet failed, exit status 1 > Cleanup : hdparm ##################### [352/638] From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 17 10:19:31 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 17 Feb 2006 11:19:31 +0100 Subject: Grub password by default? In-Reply-To: <1140113623.7777.2.camel@bree.local.net> References: <1140113240.10693.6.camel@gilboa-work-dev> <1140113623.7777.2.camel@bree.local.net> Message-ID: <20060217111931.3d1eb697@python2> Jeremy Katz wrote : > On Thu, 2006-02-16 at 20:07 +0200, Gilboa Davara wrote: > > Small question/suggestion: > > By default, Anaconda doesn't require a grub password. > > A user must manually select "Use a bootloader password" in-order to set > > on up. > > Is there a specific reason for that? > > In general, if you have physical access to the machine, you've already > lost. We allow setting the boot loader password mainly to help people > who have taken other appropriate measures (password protecting the BIOS, > ensuring the boot order doesn't boot from removable media, case locks) I totally agree : A GRUB password is only useful to people who really know why they want it. Oh, and another obvious reason why not to set one by default would be because the keyboard layout in GRUB is US, so things get confusing pretty quickly for people with different layouts, especially if they put some non alphanumeric characters in the password ;-) (please correct me if this has changed nowadays...) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.15-1.1831_FC4 Load : 0.08 0.28 0.38 From tmus at tmus.dk Fri Feb 17 10:26:15 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 17 Feb 2006 11:26:15 +0100 Subject: Bugzilla prioritised improvements list In-Reply-To: <20060216091634.7f905742@dhcp05.addix.net> References: <43F2540C.80203@fedoraproject.org> <20060216091634.7f905742@dhcp05.addix.net> Message-ID: Ralf Ertzinger wrote: > Hi. > > On Wed, 15 Feb 2006 22:22:53 +0100, Thomas M Steenholdt wrote: > >> Not sure where put put it, but i find that one of the reasons bz is >> hard to find duplicates in, are because the "devel" version under >> "fedora core" product, for example, is not about bugs in current >> rawhide, as expected, but has bugs that dates back to the "old days" > > I'm sorry? I was under the impression that FC->Devel was the category > tracking, well FC devel, which is what rawhide was some years ago. > FC devel is still referred to as rawhide on many occations - but since test X releases are effectively snapshots of rawhide at a somewhat stable point in time, picking the right distribution for querying for already reported bugs becomes just a little less straight forward... All reports filed under FC devel are still there - even bugs reported against Pre FC 1 test releases... Again - recently released test X releases (pre FC5 for example) could just as well have had bugs repported against rawhide, since we're updating from the devel tree anyways, during the testing. I'm merely suggesting that something could be done to make this a little clearer. I'll probably survive myself, but I have had the doubtful honor of filing a duplicate BZ or two (because i was not able to find the existing BZs, perhaps because of this). /Thomas From arjan at fenrus.demon.nl Fri Feb 17 10:42:41 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Fri, 17 Feb 2006 11:42:41 +0100 Subject: Please disable the SELinux execstack/relro checks before FC5 final Message-ID: <1140172961.2980.29.camel@laptopd505.fenrus.org> Hi, I'm hereby asking to disable/remove the SELinux execstack/relro checks before FC5 ships. The current state of affairs will only lead to people using big-hammer approaches in disabling selinux or big chunks thereof (based on "solutions" they find with google), which is worse than not having this protection in the first place. The technology is not finished yet. What I can imagine being useful is: 1) having the security config tool do a scan for libs/binaries that are not labeled correctly yet and present a dialog to add permissions, including an explanation of what the consequences are 2) a dbus message on failure so that the desktop can pop up a " tried to use which is most likely a security risk. In case you downloaded this plugin deliberately, make sure you want this" or something As it is right now, it's just one more thing people will just disable and hate selinux more for. From gnomeuser at gmail.com Fri Feb 17 11:28:43 2006 From: gnomeuser at gmail.com (David Nielsen) Date: Fri, 17 Feb 2006 12:28:43 +0100 Subject: Please disable the SELinux execstack/relro checks before FC5 final In-Reply-To: <1140172961.2980.29.camel@laptopd505.fenrus.org> References: <1140172961.2980.29.camel@laptopd505.fenrus.org> Message-ID: <1140175724.14908.6.camel@price.stavtrup-st.dk> fre, 17 02 2006 kl. 11:42 +0100, skrev Arjan van de Ven: > Hi, > > I'm hereby asking to disable/remove the SELinux execstack/relro checks > before FC5 ships. The current state of affairs will only lead to people > using big-hammer approaches in disabling selinux or big chunks thereof > (based on "solutions" they find with google), which is worse than not > having this protection in the first place. > > The technology is not finished yet. What I can imagine being useful is: > 1) having the security config tool do a scan for libs/binaries that are > not labeled correctly yet and present a dialog to add permissions, > including an explanation of what the consequences are > 2) a dbus message on failure so that the desktop can pop up a " application> tried to use which is most likely a > security risk. In case you downloaded this plugin deliberately, make > sure you want this" or something > > As it is right now, it's just one more thing people will just disable > and hate selinux more for. I tend to agree, it's a great feature but we need better handling of it - I assume the plan is to enable it early in the FC6 cycle again then? - David -- Obligatory shameless blog plug - the GNOME commentary located at: www.lovesunix.net/blog From n0dalus+redhat at gmail.com Fri Feb 17 12:57:36 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Fri, 17 Feb 2006 23:27:36 +1030 Subject: [ANN] Fedora Project Wiki Policy Change In-Reply-To: <200602161806.29490.nman64@n-man.com> References: <200602161806.29490.nman64@n-man.com> Message-ID: <6280325c0602170457j1d17c537qf5d4b8325e5e570c@mail.gmail.com> On 2/17/06, Patrick Barnes wrote: > > Everyone who is in the EditGroup but has not completed the CLA will be removed > after this weekend. If you are currently in the EditGroup and have not > completed the CLA, please take the time to do so now. This agreement will > allow us to license your contributions under the OPL. If you have completed > the CLA, but are removed after the weekend, contact someone in the revised > EditGroup to add you again. > What should we do if we have already completed the CLA but our wiki account has a different username to our bugzilla/accounts system account? n0dalus. From sds at tycho.nsa.gov Fri Feb 17 14:26:35 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 17 Feb 2006 09:26:35 -0500 Subject: Please disable the SELinux execstack/relro checks before FC5 final In-Reply-To: <1140172961.2980.29.camel@laptopd505.fenrus.org> References: <1140172961.2980.29.camel@laptopd505.fenrus.org> Message-ID: <1140186395.12655.245.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2006-02-17 at 11:42 +0100, Arjan van de Ven wrote: > Hi, > > I'm hereby asking to disable/remove the SELinux execstack/relro checks > before FC5 ships. The current state of affairs will only lead to people > using big-hammer approaches in disabling selinux or big chunks thereof > (based on "solutions" they find with google), which is worse than not > having this protection in the first place. > > The technology is not finished yet. What I can imagine being useful is: > 1) having the security config tool do a scan for libs/binaries that are > not labeled correctly yet and present a dialog to add permissions, > including an explanation of what the consequences are > 2) a dbus message on failure so that the desktop can pop up a " application> tried to use which is most likely a > security risk. In case you downloaded this plugin deliberately, make > sure you want this" or something > > As it is right now, it's just one more thing people will just disable > and hate selinux more for. Can you clarify exactly what you want here? I assume you mean just allow-by-default, i.e. just enable booleans in the policy by default to allow these permissions while still giving people the option to disable them if they wish. And what exact permissions are in view here: - execstack obviously - execheap? - execmod? If so, to all file types under one boolean setting, and only to texrel_shlib_t under the opposite setting? - execmem? -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Fri Feb 17 14:43:18 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 17 Feb 2006 09:43:18 -0500 Subject: Please disable the SELinux execstack/relro checks before FC5 final In-Reply-To: <1140186395.12655.245.camel@moss-spartans.epoch.ncsc.mil> References: <1140172961.2980.29.camel@laptopd505.fenrus.org> <1140186395.12655.245.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1140187398.12655.259.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2006-02-17 at 09:26 -0500, Stephen Smalley wrote: > On Fri, 2006-02-17 at 11:42 +0100, Arjan van de Ven wrote: > > Hi, > > > > I'm hereby asking to disable/remove the SELinux execstack/relro checks > > before FC5 ships. The current state of affairs will only lead to people > > using big-hammer approaches in disabling selinux or big chunks thereof > > (based on "solutions" they find with google), which is worse than not > > having this protection in the first place. > > > > The technology is not finished yet. What I can imagine being useful is: > > 1) having the security config tool do a scan for libs/binaries that are > > not labeled correctly yet and present a dialog to add permissions, > > including an explanation of what the consequences are > > 2) a dbus message on failure so that the desktop can pop up a " > application> tried to use which is most likely a > > security risk. In case you downloaded this plugin deliberately, make > > sure you want this" or something > > > > As it is right now, it's just one more thing people will just disable > > and hate selinux more for. > > Can you clarify exactly what you want here? I assume you mean just > allow-by-default, i.e. just enable booleans in the policy by default to > allow these permissions while still giving people the option to disable > them if they wish. And what exact permissions are in view here: > - execstack obviously > - execheap? > - execmod? If so, to all file types under one boolean setting, and only > to texrel_shlib_t under the opposite setting? > - execmem? Another question is what domains are in view here, e.g. all domains (such that allow_execstack permits execstack to every process rather than just unconfined processes) or just unconfined_t (so that confined daemons remain protected even if allow_execstack is enabled)? -- Stephen Smalley National Security Agency From pknirsch at redhat.com Fri Feb 17 14:54:39 2006 From: pknirsch at redhat.com (Phil Knirsch) Date: Fri, 17 Feb 2006 15:54:39 +0100 Subject: Dependency and script check mass test of current FC-devel. Message-ID: <43F5E3AF.9070907@redhat.com> Hi folks. I've just started a small script that basically does this: for each package in repo: clear buildroot yum install package in buildroot yum remove "*" in buildroot and check if there are any script and/or dependency failures. I know that quite a few of those installs are rather pointless and rather unsupported, i'm mainly doing it because i'm curious if there are any missing prereqs for scripts or any other wierd script failures. The whole thing takes ages of course and the test will most likely take till next week to finish. If anyone is interessted i'll post the results of the failures here. 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 fedora at camperquake.de Fri Feb 17 15:16:33 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 17 Feb 2006 16:16:33 +0100 Subject: gdb under FC devel and undefined symbols Message-ID: <20060217161633.005ce927@dhcp05.addix.net> Hi. I have noticed that under FC versions since FC4 the compiler seems to have gotten more aggressive with optimizations. This shows up in the following phenomenon (while debugging a "mount" segfault): (gdb) run -t nfs -o ro 172.17.128.141:/var/spool/asterisk /mnt Starting program: /bin/mount -t nfs -o ro 172.17.128.141:/var/spool/asterisk /mnt Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xd34000 Program received signal SIGSEGV, Segmentation fault. nfsmount (spec=0x92e1200 "172.17.128.141:/var/spool/asterisk", node=0x92e1228 "/mnt", flags=0xbfd7ec20, extra_opts=0xbfd7ec1c, mount_opts=0xbfd7ec18, nfs_mount_vers=0xbfd7ec10, running_bg=0) at nfsmount.c:1206 1206 if (flavor[i] == data.pseudoflavor) (gdb) whatis flavor No symbol "flavor" in current context. This has happened to me on other occassions as well. Some asking on #fedora-devel and googling shows that this is most likely due to optimization in the compiler. While this is all good and well I'd like to know how I am to debug failures like the above in the future when gdb is unable to show me variable types or contents. From rdieter at math.unl.edu Fri Feb 17 15:20:30 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 17 Feb 2006 09:20:30 -0600 Subject: Dependency and script check mass test of current FC-devel. In-Reply-To: <43F5E3AF.9070907@redhat.com> References: <43F5E3AF.9070907@redhat.com> Message-ID: <43F5E9BE.3030403@math.unl.edu> Phil Knirsch wrote: > Hi folks. > > I've just started a small script that basically does this: > > for each package in repo: > clear buildroot > yum install package in buildroot > yum remove "*" in buildroot > > and check if there are any script and/or dependency failures. Good idea. > If anyone is interessted i'll post the results of the failures here. Absolutely. -- Rex From ihok at hotmail.com Fri Feb 17 15:35:44 2006 From: ihok at hotmail.com (Jack Tanner) Date: Fri, 17 Feb 2006 10:35:44 -0500 Subject: yum upgrade from FC5test3 to FC5? Message-ID: I know that in general, yum upgrades between releases are unsupported. But could someone who's familiar with FC5test3 (esp. anaconda) say if a yum upgrade from a CD-installed FC5test3 to FC5 should cause any problems? From ivazquez at ivazquez.net Fri Feb 17 15:47:33 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 17 Feb 2006 10:47:33 -0500 Subject: yum upgrade from FC5test3 to FC5? In-Reply-To: References: Message-ID: <1140191253.2714.1.camel@ignacio.lan> On Fri, 2006-02-17 at 10:35 -0500, Jack Tanner wrote: > I know that in general, yum upgrades between releases are unsupported. > But could someone who's familiar with FC5test3 (esp. anaconda) say if a > yum upgrade from a CD-installed FC5test3 to FC5 should cause any problems? What are we, psychic? There are so many things that could change between a test release and a final release. *That's* why the upgrade is unsupported, not because the tool can't cope. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jreiser at BitWagon.com Fri Feb 17 16:38:36 2006 From: jreiser at BitWagon.com (John Reiser) Date: Fri, 17 Feb 2006 08:38:36 -0800 Subject: gdb under FC devel and undefined symbols In-Reply-To: <20060217161633.005ce927@dhcp05.addix.net> References: <20060217161633.005ce927@dhcp05.addix.net> Message-ID: <43F5FC0C.9030005@BitWagon.com> > Program received signal SIGSEGV, Segmentation fault. > nfsmount (spec=0x92e1200 "172.17.128.141:/var/spool/asterisk", node=0x92e1228 "/mnt", flags=0xbfd7ec20, extra_opts=0xbfd7ec1c, mount_opts=0xbfd7ec18, > nfs_mount_vers=0xbfd7ec10, running_bg=0) at nfsmount.c:1206 > 1206 if (flavor[i] == data.pseudoflavor) > (gdb) whatis flavor > No symbol "flavor" in current context. Assuming that 'flavor' is not a macro, then this is a bug in the compiler. A named array always resides in addressible memory, so must have a symbol visible to the debugger if the name is in scope. File a bug report against gcc. A small and simple testcase is always appreciated, but file the report anyway, naming the exact SRPM of the source and the exact gcc version, if a few attempts at simplifying fail. > While this is all good and well I'd like to know how I am to debug > failures like the above in the future when gdb is unable to show me > variable types or contents. Become familiar with assembly language and gdb's access to it. For the particular case presented above (again, assuming 'flavor' is not a macro), it isn't outrageously hard. -- From sfolkwil at redhat.com Fri Feb 17 16:40:35 2006 From: sfolkwil at redhat.com (Sam Folk-Williams) Date: Fri, 17 Feb 2006 11:40:35 -0500 Subject: yum upgrade from FC5test3 to FC5? In-Reply-To: <1140191253.2714.1.camel@ignacio.lan> References: <1140191253.2714.1.camel@ignacio.lan> Message-ID: <43F5FC83.8060900@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ignacio Vazquez-Abrams wrote: > On Fri, 2006-02-17 at 10:35 -0500, Jack Tanner wrote: >> I know that in general, yum upgrades between releases are unsupported. >> But could someone who's familiar with FC5test3 (esp. anaconda) say if a >> yum upgrade from a CD-installed FC5test3 to FC5 should cause any problems? > > What are we, psychic? There are so many things that could change between > a test release and a final release. *That's* why the upgrade is > unsupported, not because the tool can't cope. > > Hi Jack, Typically many people find that they can upgrade via yum from release to release with no major problems. You may find that yum chokes on various deps and so forth, but upgrading from test-->final will probably work. Case in point, I just upgraded via yum from FC4-->FC5test2 with no issus. Sam - -- Sam Folk-Williams, RHCE Red Hat Global Support Services GPG ID: 1024D/1B0D46BA Public Key: http://people.redhat.com/sfolkwil/sfw.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFD9fyDzOw+vBsNRroRAj1nAJ0dfu2bTmm8VibHQZWgKLkgjn1XuQCdH7Hy iappslQefcSAeSt6NPaDIxw= =jabY -----END PGP SIGNATURE----- From aph at redhat.com Fri Feb 17 16:49:58 2006 From: aph at redhat.com (Andrew Haley) Date: Fri, 17 Feb 2006 16:49:58 +0000 Subject: gdb under FC devel and undefined symbols In-Reply-To: <20060217161633.005ce927@dhcp05.addix.net> References: <20060217161633.005ce927@dhcp05.addix.net> Message-ID: <17397.65206.729055.898242@zapata.pink> Ralf Ertzinger writes: > Hi. > > I have noticed that under FC versions since FC4 the compiler seems to have > gotten more aggressive with optimizations. This shows up in the following > phenomenon (while debugging a "mount" segfault): > > (gdb) run -t nfs -o ro 172.17.128.141:/var/spool/asterisk /mnt > Starting program: /bin/mount -t nfs -o ro 172.17.128.141:/var/spool/asterisk /mnt > Reading symbols from shared object read from target memory...done. > Loaded system supplied DSO at 0xd34000 > > Program received signal SIGSEGV, Segmentation fault. > nfsmount (spec=0x92e1200 "172.17.128.141:/var/spool/asterisk", node=0x92e1228 "/mnt", flags=0xbfd7ec20, extra_opts=0xbfd7ec1c, mount_opts=0xbfd7ec18, > nfs_mount_vers=0xbfd7ec10, running_bg=0) at nfsmount.c:1206 > 1206 if (flavor[i] == data.pseudoflavor) > (gdb) whatis flavor > No symbol "flavor" in current context. > > > This has happened to me on other occassions as well. Some asking on > #fedora-devel and googling shows that this is most likely due to > optimization in the compiler. It's possible. It all depends on what `flavor' is. If it's a statically allocated variable of array or pointer type there should be debuginfo for it. If it's an auto variable gcc might have optimized it away altogether. > While this is all good and well I'd like to know how I am to debug > failures like the above in the future when gdb is unable to show me > variable types or contents. Well, the point of gcc's optimizer is to make your code faster by removing or replacing things. In this case, gcc has probably decided that `flavor' isn't needed. For example, it may have replaced the array indexing with some more efficient operation. See gcc manual, Section 3.10: Turning on optimization flags makes the compiler attempt to improve the performance and/or code size at the expense of compilation time and possibly the ability to debug the program. Andrew. From fedora at camperquake.de Fri Feb 17 16:52:29 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 17 Feb 2006 17:52:29 +0100 Subject: gdb under FC devel and undefined symbols In-Reply-To: <43F5FC0C.9030005@BitWagon.com> References: <20060217161633.005ce927@dhcp05.addix.net> <43F5FC0C.9030005@BitWagon.com> Message-ID: <20060217175229.77204c6d@dhcp05.addix.net> Hi. On Fri, 17 Feb 2006 08:38:36 -0800, John Reiser wrote: > Assuming that 'flavor' is not a macro, then this is a bug in the > compiler. flavor is a *int: int i, *flavor, yum = 0; > Become familiar with assembly language and gdb's access to it. > For the particular case presented above (again, assuming 'flavor' > is not a macro), it isn't outrageously hard. If you'd happen to have a pointer handy I'd be most grateful. x86 assembler is not a total stranger to me. From jspaleta at gmail.com Fri Feb 17 16:56:53 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 17 Feb 2006 11:56:53 -0500 Subject: yum upgrade from FC5test3 to FC5? In-Reply-To: <43F5FC83.8060900@redhat.com> References: <1140191253.2714.1.camel@ignacio.lan> <43F5FC83.8060900@redhat.com> Message-ID: <604aa7910602170856x528b864gb9d6b3a8e58a858a@mail.gmail.com> On 2/17/06, Sam Folk-Williams wrote: > deps and so forth, but upgrading from test-->final will probably work. Can you really say probably? I think you are misleading people and encouraging inflated expectations. Doesn't anaconda do some specific actions in ramdisk that can not be done on live systems depending on specific hardware and system configurations? If you aren't personally running one of those situations how can you claim that other users probably won't be? I would personally say nothing stronger than "may" work to keep expectations on success as low as possible to minimize frustration when it doesn't work. Inappropriate Inflated expectations are the leading factor in frustrations in my personal experience. In the future, there may very well be a provided way forward to do yum based upgrades from a dropin ramdisk image you can add into grub and then reboot into the upgrade process. But thats not provided yet.. and I don't think its wise to tell users they "probably" can do a live upgrade without knowing details about what their system configuration is and a summary of special ramdisk actions anaconda takes for those situations. -jef From kwade at redhat.com Fri Feb 17 16:57:48 2006 From: kwade at redhat.com (Karsten Wade) Date: Fri, 17 Feb 2006 08:57:48 -0800 Subject: [ANN] Fedora Project Wiki Policy Change In-Reply-To: <6280325c0602170457j1d17c537qf5d4b8325e5e570c@mail.gmail.com> References: <200602161806.29490.nman64@n-man.com> <6280325c0602170457j1d17c537qf5d4b8325e5e570c@mail.gmail.com> Message-ID: <1140195468.18050.396.camel@erato.phig.org> Sorry, rejected this one by mistake, you weren't subscribed to some of the lists. Informative for all: On Fri, 2006-02-17 at 23:27 +1030, n0dalus wrote: > What should we do if we have already completed the CLA but our wiki > account has a different username to our bugzilla/accounts system > account? The connection between Wiki and CLA is manual, that is, Patrick et al are looking over the lists and making comparisons. If someone has wildly different usernames, you'll be asked to sign a CLA, and you can just reply back that you have one and under what name. Your GPG signature on that email would seal the deal. :) We'll be sure to make that point in the email to the people we request a CLA from. Thanks - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kevinverma at gmail.com Fri Feb 17 17:00:23 2006 From: kevinverma at gmail.com (Kevin Verma) Date: Fri, 17 Feb 2006 22:30:23 +0530 Subject: Questioning Pirut Message-ID: Dear Pirut Developers, I've been trying to use Pirut over the FC5 rawhide, referring a screen shot here from the wiki, http://fedoraproject.org/wiki/Tours/FedoraCore5/007_Pirut I will like to know your point of view why we really needed yet another package manager, I understand that this one is created more to adapt to Yum system. I will like to know your view if system-config-packages could have been adapted to Yum as well ? And what are the projections with this tool ahead, I will also like to point out that this tool is not working much as good enough on lower resolution of 800x600 I have read it somewhere that the developer accepting this tool does not look much eye candy yet, but can we please have a peer view of the mock they have in mind this tool will look like. Please respond, flames are welcome but I just wanted to be more clear. If some one can also tell me how up2date will be tested with Fedora ahead or Red Hat is keeping that out of Fedora and still plan to use it ahead for RHN. Cheers, From mailinglists at erwinrol.com Fri Feb 17 17:22:17 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 17 Feb 2006 18:22:17 +0100 Subject: Questioning Pirut In-Reply-To: References: Message-ID: <1140196937.17385.294.camel@xpc.home.erwinrol.com> On Fri, 2006-02-17 at 22:30 +0530, Kevin Verma wrote: > And what are the projections with this tool ahead, I will also like to > point out that this tool is not working much as good enough on lower > resolution of 800x600 I have read it somewhere that the developer > accepting this tool does not look much eye candy yet, but can we > please have a peer view of the mock they have in mind this tool will > look like. Pirut's GUI is just in a poor pre-alpha state, it hardly follows the Gnome HIG, it can't do full screen, strange large font, the GUI sometimes locks up when doing "networking" work, and the icons are just terrible. If it is going to be shipped in FC5 like this it will just be a plain embarrassment for Fedora. Of course that does not mean pirut doesn't have potential and certainly doesn't mean the pirut developers are doing a poor job, it is simply means pirut is not ready yet. > Please respond, flames are welcome but I just wanted to be more clear. > If some one can also tell me how up2date will be tested with Fedora > ahead or Red Hat is keeping that out of Fedora and still plan to use > it ahead for RHN. I always wondered when happened to red carpet, that was a great RPM update manager, with a good GUI. Its a shame that isn't part of Fedora Core (technicalities apart, because it would probably be a bitch to make it use yum). - Erwin From stickster at gmail.com Fri Feb 17 17:30:55 2006 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 17 Feb 2006 12:30:55 -0500 Subject: Questioning Pirut In-Reply-To: References: Message-ID: <1140197455.3317.4.camel@localhost.localdomain> On Fri, 2006-02-17 at 22:30 +0530, Kevin Verma wrote: > Dear Pirut Developers, > > I've been trying to use Pirut over the FC5 rawhide, referring a screen > shot here from the wiki, > http://fedoraproject.org/wiki/Tours/FedoraCore5/007_Pirut > > I will like to know your point of view why we really needed yet > another package manager, I understand that this one is created more to > adapt to Yum system. I will like to know your view if > system-config-packages could have been adapted to Yum as well ? Pirut replaces system-config-packages. [...snip...] > Please respond, flames are welcome but I just wanted to be more clear. > If some one can also tell me how up2date will be tested with Fedora > ahead or Red Hat is keeping that out of Fedora and still plan to use > it ahead for RHN. Pup replaces up2date. There is no notification icon but I think I heard rumblings on this list (see archives) that someone was working on one using libnotify et al. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-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 Fri Feb 17 18:03:18 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 17 Feb 2006 13:03:18 -0500 Subject: Questioning Pirut In-Reply-To: <1140196937.17385.294.camel@xpc.home.erwinrol.com> References: <1140196937.17385.294.camel@xpc.home.erwinrol.com> Message-ID: <604aa7910602171003j6ae6b71eiedcefdc8a86feac0@mail.gmail.com> On 2/17/06, Erwin Rol wrote: > Of course that does not mean pirut doesn't have potential and > certainly doesn't mean the pirut developers are doing a poor job, it is > simply means pirut is not ready yet. and system-packages-configs has severe limitations which may nullify its usefulness all together in the restructuring of groups going on as part of FC5 development. and up2date has its own limitations which will nullify its usefulness for FC5. When all available options are suboptimal, perhaps the best solutions aren't mature codebases with the optimized UI that don't work with the repository framework in use. Maybe the best suboptimal solution on the board is the new codebase that is designed to work with the framework regardless of how immature its UI is and we will just have to live with it for fc5 and work on ui issues in fc6 development. -jef From jreiser at BitWagon.com Fri Feb 17 18:36:21 2006 From: jreiser at BitWagon.com (John Reiser) Date: Fri, 17 Feb 2006 10:36:21 -0800 Subject: gdb under FC devel and undefined symbols In-Reply-To: <20060217175229.77204c6d@dhcp05.addix.net> References: <20060217161633.005ce927@dhcp05.addix.net> <43F5FC0C.9030005@BitWagon.com> <20060217175229.77204c6d@dhcp05.addix.net> Message-ID: <43F617A5.8060007@BitWagon.com> > flavor is a *int: > > int i, *flavor, yum = 0; Because flavor is a scalar, it is often somewhat easy for the compiler to "eliminate" it, leaving no memory location where it resides. In many cases a register is assigned. If for an entire statement, then the register could be tagged as the location of the variable, but if for less than an entire statement then it gets cloudy as to what is reasonable. > x86 assembler is not a total stranger to me. The one-minute into is: (gdb) x/4i $pc # next instruction and following 3 (gdb) x/12i $pc-0x18 # heuristic for plausible previous instructions (gdb) p $eax # register %eax (gdb) p $ebp # stack frame pointer, if used as such (gdb) stepi # single-step one instruction -- From arjan at fenrus.demon.nl Fri Feb 17 20:12:23 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Fri, 17 Feb 2006 21:12:23 +0100 Subject: Please disable the SELinux execstack/relro checks before FC5 final In-Reply-To: <1140186395.12655.245.camel@moss-spartans.epoch.ncsc.mil> References: <1140172961.2980.29.camel@laptopd505.fenrus.org> <1140186395.12655.245.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1140207144.2980.53.camel@laptopd505.fenrus.org> On Fri, 2006-02-17 at 09:26 -0500, Stephen Smalley wrote: > On Fri, 2006-02-17 at 11:42 +0100, Arjan van de Ven wrote: > > Hi, > > > > I'm hereby asking to disable/remove the SELinux execstack/relro checks > > before FC5 ships. The current state of affairs will only lead to people > > using big-hammer approaches in disabling selinux or big chunks thereof > > (based on "solutions" they find with google), which is worse than not > > having this protection in the first place. > > > > The technology is not finished yet. What I can imagine being useful is: > > 1) having the security config tool do a scan for libs/binaries that are > > not labeled correctly yet and present a dialog to add permissions, > > including an explanation of what the consequences are > > 2) a dbus message on failure so that the desktop can pop up a " > application> tried to use which is most likely a > > security risk. In case you downloaded this plugin deliberately, make > > sure you want this" or something > > > > As it is right now, it's just one more thing people will just disable > > and hate selinux more for. > > Can you clarify exactly what you want here? I assume you mean just > allow-by-default, i.e. just enable booleans in the policy by default to > allow these permissions while still giving people the option to disable > them if they wish. sure that's fair enough > And what exact permissions are in view here: > - execstack obviously > - execheap? that needs to be treated the same as execstack; permissive by default > - execmod? If so, to all file types under one boolean setting, and only > to texrel_shlib_t under the opposite setting? > - execmem? all by default set to "allow" (and yes I would LOVE for it to be otherwise, but right now it just isn't ready) From arjan at fenrus.demon.nl Fri Feb 17 20:14:29 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Fri, 17 Feb 2006 21:14:29 +0100 Subject: Please disable the SELinux execstack/relro checks before FC5 final In-Reply-To: <1140187398.12655.259.camel@moss-spartans.epoch.ncsc.mil> References: <1140172961.2980.29.camel@laptopd505.fenrus.org> <1140186395.12655.245.camel@moss-spartans.epoch.ncsc.mil> <1140187398.12655.259.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1140207269.2980.57.camel@laptopd505.fenrus.org> > Another question is what domains are in view here, e.g. all domains > (such that allow_execstack permits execstack to every process rather > than just unconfined processes) or just unconfined_t (so that confined > daemons remain protected even if allow_execstack is enabled)? right now I fear the only sane answer is "set all to permissive behavior"; the minimum for fc5 would be everything that can do plugins of any kind, or uses libraries that tend to get replaced (3D ones ;). But that ends up being a whole whopping lot... I really wish the user notification/config thing existed, but that will take time to get right for sure... From linux_4ever at yahoo.com Fri Feb 17 21:03:12 2006 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 17 Feb 2006 13:03:12 -0800 (PST) Subject: Please disable the SELinux execstack/relro checks before FC5 final In-Reply-To: <1140207269.2980.57.camel@laptopd505.fenrus.org> Message-ID: <20060217210312.29958.qmail@web51501.mail.yahoo.com> >I really wish the user notification/config thing existed, but that will >take time to get right for sure... I've been planning to make this a plugin to the audit event dispatcher. All the hooks are there so that it could be written today. I can help out with the event identification piece and getting it into dbus, but need someone else to do the GUI side of it. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From chitlesh at fedoraproject.org Fri Feb 17 22:31:12 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Fri, 17 Feb 2006 23:31:12 +0100 Subject: yum upgrade from FC5test3 to FC5? In-Reply-To: <1140191253.2714.1.camel@ignacio.lan> References: <1140191253.2714.1.camel@ignacio.lan> Message-ID: <13dbfe4f0602171431r24d60e13u761e9bac7fbdbdb7@mail.gmail.com> > What are we, psychic? There are so many things that could change between > a test release and a final release. *That's* why the upgrade is > unsupported, not because the tool can't cope. just a question! you know debian does update with apt-get the debian guys use this issue to advertise the advantages of their distro but how can one defend yum here? From jspaleta at gmail.com Fri Feb 17 22:39:56 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 17 Feb 2006 17:39:56 -0500 Subject: yum upgrade from FC5test3 to FC5? In-Reply-To: <13dbfe4f0602171431r24d60e13u761e9bac7fbdbdb7@mail.gmail.com> References: <1140191253.2714.1.camel@ignacio.lan> <13dbfe4f0602171431r24d60e13u761e9bac7fbdbdb7@mail.gmail.com> Message-ID: <604aa7910602171439i5c57cef4m181c7532a771b10@mail.gmail.com> On 2/17/06, Chitlesh GOORAH wrote: > just a question! > you know debian does update with apt-get > the debian guys use this issue to advertise the advantages of their distro > but how can one defend yum here? go back and take a look at the complaints from users in the debian lists when the newest stable release of debian landed and determine for yourself if the level of advertising the do with regard to live upgrades is appropriate, or is it overly optimistic expectations? The reality is... fedora moves fast... it integrates new technologies at all levels of the software stack..fast. Some of these technology shifts (especially filesystem level) can not always be handled adequately from inside the running system where the filesystems are in use. While the release team and developers can accurately prepare migration magic for these situations, some of them will need to be run from a ramdisk (like anaconda does). There is nothing stopping producing a ramdisk image that runs yum in a similar manner with appropriate defined pre/post upgrade magic.. nothng stopping it except finite developer resources... and i'm pretty sure things are moving in a direction where this will be possible to provide. BUT you can not get around the need for a reboot into a ramdisk based mini-system so that your actual system is not in use for all situations on in the wild. -jef From chitlesh at fedoraproject.org Fri Feb 17 22:56:57 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Fri, 17 Feb 2006 23:56:57 +0100 Subject: rawhide report: 20060217 changes In-Reply-To: <200602170819.k1H8JI1T011188@porkchop.devel.redhat.com> References: <200602170819.k1H8JI1T011188@porkchop.devel.redhat.com> Message-ID: <13dbfe4f0602171456r7e56b128x66b7271a71c07ff7@mail.gmail.com> On 2/17/06, Build System wrote: > > > > Updated Packages: > > xorg-x11-drivers-7.0-2 > ---------------------- > * Thu Feb 16 2006 Bill Nottingham - 7.0-2 > - uncomment (empty) file list so binary RPMs are built > > * Fri Feb 10 2006 Jesse Keating - 7.0-1.1 > - bump again for double-long bug on ppc(64) > > * Thu Feb 09 2006 Mike Harris 7.0-1 > - Bumped version to 7.0-1 > - Updated the driver list to match current rawhide, X11R7.0 > > > > > Broken deps for ia64 > ---------------------------------------------------------- > rgmanager - 1.9.31-3.ia64 requires ccs > vconfig - 1.9-1.1.ia64 requires libc.so.6 > vconfig - 1.9-1.1.ia64 requires libc.so.6(GLIBC_2.0) > > > > Broken deps for ppc > ---------------------------------------------------------- > gulm-devel - 1.0.0-2.ppc requires gulm = 0:1.0.0-2 > magma-plugins - 1.0.3-1.FC5.ppc requires libgulm.so.1 > magma-plugins - 1.0.3-1.FC5.ppc requires libdlm_lt.so.1 > > > > Broken deps for ppc64 > ---------------------------------------------------------- > emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi > gulm-devel - 1.0.0-2.ppc64 requires gulm = 0:1.0.0-2 > magma-plugins - 1.0.3-1.FC5.ppc64 requires libdlm_lt.so.1()(64bit) > magma-plugins - 1.0.3-1.FC5.ppc64 requires libgulm.so.1()(64bit) > vconfig - 1.9-1.1.ppc64 requires libc.so.6 > vconfig - 1.9-1.1.ppc64 requires libc.so.6(GLIBC_2.0) > > > > Broken deps for s390 > ---------------------------------------------------------- > rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 > rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 > rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 > > > > Broken deps for s390x > ---------------------------------------------------------- > rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) > rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) > rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) since days i was looking forward to post my dependencies: Missing Dependency: libwx_gtk2-2.4.so.0 is needed by package wxPythonGTK2 Missing Dependency: libwx_gtk2-2.4.so.0(WXGTK2_2.4) is needed by package wxPythonGTK2 Missing Dependency: libwx_gtk2_gl-2.4.so.0(WXGTK2_2.4) is needed by package wxPythonGTK2 Missing Dependency: libwx_gtk2_gl-2.4.so.0 is needed by package wxPythonGTK2 with wxGTK-gl-2.6.2-4.fc5 compat-wxGTK2-gl-2.4.2-16.fc5 wxGTK-devel-2.6.2-4.fc5 compat-wxGTK-common-2.4.2-16.fc5 compat-wxGTK2-2.4.2-16.fc5 wxGTK-2.6.2-4.fc5 -- http://clunixchit.blogspot.com From dhollis at davehollis.com Fri Feb 17 14:43:01 2006 From: dhollis at davehollis.com (David Hollis) Date: Fri, 17 Feb 2006 09:43:01 -0500 Subject: OpenLDAP config update from RPM In-Reply-To: <1140129969.17385.246.camel@xpc.home.erwinrol.com> References: <1140129969.17385.246.camel@xpc.home.erwinrol.com> Message-ID: <1140187381.15963.2.camel@dhollis-lnx.sunera.com> On Thu, 2006-02-16 at 23:46 +0100, Erwin Rol wrote: > Hey all, > > I am working on Open Xchange for FC5, and was wondering what the > "correct" way is to add things to a openldap configuration from "inside" > an RPM. > > For example Open Xchange has a openxchange.schema file with schemas, > that i install in /etc/openldap/schema/. Open Xchange also has a file > describing the access rights and indexing, those have to be added to > the /etc/openldap/slapd.conf file. The question is is there a way to add > configuration things to OpenLDAP in the same way as for example with > apache (the conf.d directory) ? Or is the only thing i can do installing > a README and have the user add those things manually ? > Being an Open-Xchange user, I would suggest the following: Install the open-xchange.schema file in /etc/openldap/schemas Install the access-rights file in /etc/openldap as open-xchange-rights.conf or something to that effect. Don't actually edit the /etc/openldap/slapd.conf file itself, that should be left to the admin. The access rights bits can be included by the admin with a simple "include open-xchange-access.conf" statement. -- David Hollis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From mailinglists at erwinrol.com Sat Feb 18 00:16:28 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sat, 18 Feb 2006 01:16:28 +0100 Subject: OpenLDAP config update from RPM In-Reply-To: <1140187381.15963.2.camel@dhollis-lnx.sunera.com> References: <1140129969.17385.246.camel@xpc.home.erwinrol.com> <1140187381.15963.2.camel@dhollis-lnx.sunera.com> Message-ID: <1140221788.17385.302.camel@xpc.home.erwinrol.com> On Fri, 2006-02-17 at 09:43 -0500, David Hollis wrote: > On Thu, 2006-02-16 at 23:46 +0100, Erwin Rol wrote: > > Being an Open-Xchange user, I would suggest the following: > > Install the open-xchange.schema file in /etc/openldap/schemas > Install the access-rights file in /etc/openldap as > open-xchange-rights.conf or something to that effect. Don't actually > edit the /etc/openldap/slapd.conf file itself, that should be left to > the admin. The access rights bits can be included by the admin with a > simple "include open-xchange-access.conf" statement. That is what i did now, because i saw some other RPM's that used "patch" to change system config files like postgres, openldap and httpd/tomcat setups, but that some how looks just to dangerous to me. And if you as a user also think that the final configuration step is an admin job , i will just leave it as I have it now. Thanks for the feedback, Erwin From fcd-cornette at insight.rr.com Sat Feb 18 02:12:14 2006 From: fcd-cornette at insight.rr.com (Jim Cornette) Date: Fri, 17 Feb 2006 21:12:14 -0500 Subject: yum upgrade from FC5test3 to FC5? In-Reply-To: <13dbfe4f0602171431r24d60e13u761e9bac7fbdbdb7@mail.gmail.com> References: <1140191253.2714.1.camel@ignacio.lan> <13dbfe4f0602171431r24d60e13u761e9bac7fbdbdb7@mail.gmail.com> Message-ID: <43F6827E.8050808@insight.rr.com> Chitlesh GOORAH wrote: >> What are we, psychic? There are so many things that could change between >> a test release and a final release. *That's* why the upgrade is >> unsupported, not because the tool can't cope. > > just a question! > you know debian does update with apt-get > the debian guys use this issue to advertise the advantages of their distro > but how can one defend yum here? > apt-get and dselect (i believe) are alright for some purposes. I did have more problems with apt-get pulling a working system by removing critical packages. Yum on the other hand fails with a dependably problem and fails. The compiler language for apt-get seems to be quicker acting than the programming language that yum uses. The logic regarding upgrading is better in my view for the yum approach. Jim -- The easiest way to get the root password is to become system admin. -- Unknown source From drepper at redhat.com Sat Feb 18 02:48:59 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Fri, 17 Feb 2006 18:48:59 -0800 Subject: Please disable the SELinux execstack/relro checks before FC5 final In-Reply-To: <1140207269.2980.57.camel@laptopd505.fenrus.org> References: <1140172961.2980.29.camel@laptopd505.fenrus.org> <1140186395.12655.245.camel@moss-spartans.epoch.ncsc.mil> <1140187398.12655.259.camel@moss-spartans.epoch.ncsc.mil> <1140207269.2980.57.camel@laptopd505.fenrus.org> Message-ID: <43F68B1B.5080002@redhat.com> Arjan van de Ven wrote: > right now I fear the only sane answer is "set all to permissive > behavior"; the minimum for fc5 would be everything that can do plugins > of any kind, or uses libraries that tend to get replaced (3D ones ;). > But that ends up being a whole whopping lot... I'm not so sure. The most crappy software are all those mozilla/firefox/thunderbird plugins. So, yes, we might need more time for that although I'd rather prefer to have a separate domain for those programs. The NVidia driver also needs an executable stack but nothing else. What I have not seen are programs which have their own domain and still need any of the booleans set. Somebody should show real evidence that any of those domains need the permission checks disable. If we cannot move the moz/ffox/tbird into their own domain then, yes, disable the checks for unconfined processes. But we should keep the tests for all programs which have their own domain. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From tla-ml at rasmil.dk Sat Feb 18 06:15:57 2006 From: tla-ml at rasmil.dk (Tim Lauridsen) Date: Sat, 18 Feb 2006 07:15:57 +0100 Subject: Questioning Pirut In-Reply-To: References: Message-ID: <43F6BB9D.6070703@rasmil.dk> Kevin Verma wrote: > Dear Pirut Developers, > > I've been trying to use Pirut over the FC5 rawhide, referring a screen > shot here from the wiki, > http://fedoraproject.org/wiki/Tours/FedoraCore5/007_Pirut > > I will like to know your point of view why we really needed yet > another package manager, I understand that this one is created more to > adapt to Yum system. I will like to know your view if > system-config-packages could have been adapted to Yum as well ? > > And what are the projections with this tool ahead, I will also like to > point out that this tool is not working much as good enough on lower > resolution of 800x600 I have read it somewhere that the developer > accepting this tool does not look much eye candy yet, but can we > please have a peer view of the mock they have in mind this tool will > look like. > > Please respond, flames are welcome but I just wanted to be more clear. > If some one can also tell me how up2date will be tested with Fedora > ahead or Red Hat is keeping that out of Fedora and still plan to use > it ahead for RHN. > > Cheers, > > I have suggested to the developers to join forces and get Yum Extender a.k.a yumex in shape to get into Core. I takes time to make a good package manager gui and there are no need to start from scratch. pup and system-install-packages are in good shape, but pirut need a lot of work. The current development release of yumex 0.99.9, currently in extras-development, is in good shape and works in both FC4 and rawhide. (and in RHEL 4 (with yum 2.4.x & CentOS 4.2) Tim Lauridsen Yumex Developer. From benjy.grogan at gmail.com Sat Feb 18 07:04:05 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Sat, 18 Feb 2006 02:04:05 -0500 Subject: Questioning Pirut In-Reply-To: <1140197455.3317.4.camel@localhost.localdomain> References: <1140197455.3317.4.camel@localhost.localdomain> Message-ID: On 2/17/06, Paul W. Frields wrote: > > > [...snip...] > > Please respond, flames are welcome but I just wanted to be more clear. > > If some one can also tell me how up2date will be tested with Fedora > > ahead or Red Hat is keeping that out of Fedora and still plan to use > > it ahead for RHN. > > Pup replaces up2date. There is no notification icon but I think I heard > rumblings on this list (see archives) that someone was working on one > using libnotify et al. > Aren't the days of libnotify over? Isn't D-Bus the replacement for all system/console messages? Is libnotify still being implemented as a back up? Benji -------------- next part -------------- An HTML attachment was scrubbed... URL: From buildsys at redhat.com Sat Feb 18 08:22:47 2006 From: buildsys at redhat.com (Build System) Date: Sat, 18 Feb 2006 03:22:47 -0500 Subject: rawhide report: 20060218 changes Message-ID: <200602180822.k1I8Mlie000454@porkchop.devel.redhat.com> Updated Packages: (none) Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs vconfig - 1.9-1.1.ia64 requires libc.so.6 vconfig - 1.9-1.1.ia64 requires libc.so.6(GLIBC_2.0) Broken deps for ppc64 ---------------------------------------------------------- emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi vconfig - 1.9-1.1.ppc64 requires libc.so.6 vconfig - 1.9-1.1.ppc64 requires libc.so.6(GLIBC_2.0) Broken deps for s390 ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 Broken deps for s390x ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) From michael.favia at insitesinc.com Sat Feb 18 08:27:39 2006 From: michael.favia at insitesinc.com (Michael Favia) Date: Sat, 18 Feb 2006 02:27:39 -0600 Subject: rawhide report: 20060218 changes In-Reply-To: <200602180822.k1I8Mlie000454@porkchop.devel.redhat.com> References: <200602180822.k1I8Mlie000454@porkchop.devel.redhat.com> Message-ID: <43F6DA7B.8070109@insitesinc.com> Build System wrote: > Updated Packages: > (none) busy day huh? ;) -mf From caillon at redhat.com Sat Feb 18 09:09:21 2006 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 18 Feb 2006 04:09:21 -0500 Subject: rawhide report: 20060217 changes In-Reply-To: <13dbfe4f0602171456r7e56b128x66b7271a71c07ff7@mail.gmail.com> References: <200602170819.k1H8JI1T011188@porkchop.devel.redhat.com> <13dbfe4f0602171456r7e56b128x66b7271a71c07ff7@mail.gmail.com> Message-ID: <43F6E441.3080305@redhat.com> On 02/17/2006 05:56 PM, Chitlesh GOORAH wrote: > since days i was looking forward to post my dependencies: > > Missing Dependency: libwx_gtk2-2.4.so.0 is needed by package wxPythonGTK2 > Missing Dependency: libwx_gtk2-2.4.so.0(WXGTK2_2.4) is needed by > package wxPythonGTK2 > Missing Dependency: libwx_gtk2_gl-2.4.so.0(WXGTK2_2.4) is needed by > package wxPythonGTK2 > Missing Dependency: libwx_gtk2_gl-2.4.so.0 is needed by package wxPythonGTK2 > > with > wxGTK-gl-2.6.2-4.fc5 > compat-wxGTK2-gl-2.4.2-16.fc5 > wxGTK-devel-2.6.2-4.fc5 > compat-wxGTK-common-2.4.2-16.fc5 > compat-wxGTK2-2.4.2-16.fc5 > wxGTK-2.6.2-4.fc5 You realize that those are part of Fedora Extras, not Core, right? From gnomeuser at gmail.com Sat Feb 18 09:11:31 2006 From: gnomeuser at gmail.com (David Nielsen) Date: Sat, 18 Feb 2006 10:11:31 +0100 Subject: rawhide report: 20060218 changes In-Reply-To: <43F6DA7B.8070109@insitesinc.com> References: <200602180822.k1I8Mlie000454@porkchop.devel.redhat.com> <43F6DA7B.8070109@insitesinc.com> Message-ID: <1140253891.2244.6.camel@price.stavtrup-st.dk> l?r, 18 02 2006 kl. 02:27 -0600, skrev Michael Favia: > Build System wrote: > > Updated Packages: > > (none) > busy day huh? ;) > -mf devel freeze for Test3, I'm sure we will se new updates following Monday' release. - David -- Obligatory shameless blog plug - the GNOME commentary located at: www.lovesunix.net/blog From enrico.scholz at informatik.tu-chemnitz.de Sat Feb 18 10:30:33 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 18 Feb 2006 11:30:33 +0100 Subject: dietlibc compilation error in PPC Message-ID: <8764ndvu0m.fsf@kosh.bigo.ensc.de> Hello, compilation of dietlibc in devel branch fails on PPC machine at code like | 36 #define B0 + 1.0l/ 6/ 1/ 2 | ... | 50 static const double coeff[] = { B0, ... }; The error message is | libm/gamma.c:50: error: initializer element is not constant | libm/gamma.c:50: error: (near initialization for 'coeff[0]') This code looks sane to me, it builds fine on i386 and I do not have a PPC machine where I can trace it down further. Has somebody an idea about the reason of this behavior? The complete log is available at http://buildsys.fedoraproject.org/logs/fedora-development-extras/4838-dietlibc-0.29-5.fc5/ppc/build.log where the sources are located too. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From link at pobox.com Sat Feb 18 10:42:50 2006 From: link at pobox.com (Terje Bless) Date: Sat, 18 Feb 2006 11:42:50 +0100 Subject: Questioning Pirut In-Reply-To: <1140196937.17385.294.camel@xpc.home.erwinrol.com> Message-ID: Erwin Rol wrote: >I always wondered when happened to red carpet It's now a part of Novell's ZENworks Linux Management. See . According to our Novell rep, it also can be deployed on RHEL systems (as well as SUSE) for a common centralized management platform. Of course, as such it's in direct competition with the RHN product line from Red Hat ? and probably their main strategy for gaining market share ? so I somehow doubt we'll see any Red Hat initiatives to adopt it. Not that it can very easily be repurposed to be independent of Novell's ZLM infrastructure ? that I can see anyway ? so I suspect it'd be a poor fit for Fedora in any case. -- I'm [less] than thrilled by the [VM situation]; all sides of it. I [think] we need a [fork] in that area so that you guys would stop stepping on each others' toes. I'm taking no part in your merry 5-way clusterfuck -- sort that mess out between yourselves. -- Alexander Viro on lkml From hellwolf at seu.edu.cn Sat Feb 18 11:56:33 2006 From: hellwolf at seu.edu.cn (ZC Miao) Date: Sat, 18 Feb 2006 19:56:33 +0800 Subject: some mimetype lost icons Message-ID: <1140263793.5060.8.camel@cocteau.hellwolf-misty.org> I use: shared-mime-info-0.16.cvs20060212-3 redhat-artwork-0.238-1.1 fedora-logos-1.1.41-1 gnome-icon-theme-2.14.0-2 And now, some mimetypes such as: audio/mpeg text/html have no icons(looks very ugly) -- ZC Miao http://hellwolf.cublog.cn/ gpg --keyserver keyserver.veridis.com --recv-key 0x6B174C6F -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From walovaton at yahoo.com.mx Sat Feb 18 15:03:11 2006 From: walovaton at yahoo.com.mx (William Lovaton) Date: Sat, 18 Feb 2006 10:03:11 -0500 Subject: Yum and SRPMs In-Reply-To: <1140126778.2437.23.camel@ender> References: <1133079326.2854.1.camel@entropy> <20051128124649.GB29992@jadzia.bu.edu> <1133185654.21208.124.camel@cutter> <6280325c0511280703v2c514df8p63c31ca9cf06def7@mail.gmail.com> <1133190580.6952.0.camel@cutter> <604aa7910511280719l59f4921bja4c15e160cfb4e77@mail.gmail.com> <1133195955.16284.1.camel@weasel.turre.laiskiainen.org> <604aa7910511280856g3f043934g4c7da09e83ed181a@mail.gmail.com> <1140126778.2437.23.camel@ender> Message-ID: <1140274991.2211.11.camel@athlon2000> Hi, El jue, 16-02-2006 a las 13:52 -0800, Jesse Keating escribi??: > I made a small mistake. The unified SRPMS and srpm repodata will be > useful for yumdownloader, not yum itself. Yum does not and will not > have the ability to grab srpms. yumdownloader? I hope it is what I am thinking. You'll see, my home computer is connected to the Internet through a modem and most of the time making updates is prohibited because more often that not they are very large, so I religiously copy the packages names that needs an update, I take them to my office and wget them from a very fast connection one by one into my usb memory and finally back to my home and copy the packages in the yum cache. Is there a way to make the downloading part of this automatic? something like yum generating all the wget commands so I can use them on a very fast connection easily instead of one by one. I like to use the following command: whet -cb http://server/package.rpm BTW, I am using FC4 at home and FC3 at work. Thanks in advance, -William __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ?gratis! Reg?strate ya - http://correo.yahoo.com.mx/ From buildsys at redhat.com Sun Feb 19 08:57:41 2006 From: buildsys at redhat.com (Build System) Date: Sun, 19 Feb 2006 03:57:41 -0500 Subject: rawhide report: 20060219 changes Message-ID: <200602190857.k1J8vfM8032365@porkchop.devel.redhat.com> Updated Packages: (none) Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs vconfig - 1.9-1.1.ia64 requires libc.so.6 vconfig - 1.9-1.1.ia64 requires libc.so.6(GLIBC_2.0) Broken deps for ppc64 ---------------------------------------------------------- emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi vconfig - 1.9-1.1.ppc64 requires libc.so.6 vconfig - 1.9-1.1.ppc64 requires libc.so.6(GLIBC_2.0) Broken deps for s390 ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 Broken deps for s390x ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) From sundaram at fedoraproject.org Sun Feb 19 11:49:49 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 19 Feb 2006 17:19:49 +0530 Subject: Questioning Pirut In-Reply-To: References: Message-ID: <43F85B5D.50309@fedoraproject.org> Kevin Verma wrote: >Dear Pirut Developers, > >I've been trying to use Pirut over the FC5 rawhide, referring a screen >shot here from the wiki, >http://fedoraproject.org/wiki/Tours/FedoraCore5/007_Pirut > >I will like to know your point of view why we really needed yet >another package manager, I understand that this one is created more to >adapt to Yum system. I will like to know your view if >system-config-packages could have been adapted to Yum as well ? > > > That is exactly what pirut is. A adoption of system-config-packages to use a yum backend with a new name to reflect the fact that the tool doesnt require any configuration. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From sundaram at fedoraproject.org Sun Feb 19 11:50:46 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 19 Feb 2006 17:20:46 +0530 Subject: Questioning Pirut In-Reply-To: <1140196937.17385.294.camel@xpc.home.erwinrol.com> References: <1140196937.17385.294.camel@xpc.home.erwinrol.com> Message-ID: <43F85B96.2010006@fedoraproject.org> Erwin Rol wrote: >On Fri, 2006-02-17 at 22:30 +0530, Kevin Verma wrote: > > > >>And what are the projections with this tool ahead, I will also like to >>point out that this tool is not working much as good enough on lower >>resolution of 800x600 I have read it somewhere that the developer >>accepting this tool does not look much eye candy yet, but can we >>please have a peer view of the mock they have in mind this tool will >>look like. >> >> > >Pirut's GUI is just in a poor pre-alpha state, it hardly follows the >Gnome HIG, it can't do full screen, strange large font, the GUI >sometimes locks up when doing "networking" work, and the icons are just >terrible. If it is going to be shipped in FC5 like this it will just be >a plain embarrassment for Fedora. > I bet that a list of bug reports would be better to a non constructive flame. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From sundaram at fedoraproject.org Sun Feb 19 11:51:48 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 19 Feb 2006 17:21:48 +0530 Subject: Questioning Pirut In-Reply-To: References: <1140197455.3317.4.camel@localhost.localdomain> Message-ID: <43F85BD4.3060105@fedoraproject.org> Hi, Benjy Grogan wrote: > > >Aren't the days of libnotify over? > No. > Isn't D-Bus the replacement for all >system/console messages? > No. > Is libnotify still being implemented as a back up? > > Yes. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From mailinglists at erwinrol.com Sun Feb 19 13:37:40 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sun, 19 Feb 2006 14:37:40 +0100 Subject: spec file question Message-ID: <1140356261.17385.336.camel@xpc.home.erwinrol.com> Hey all, A small question to the rpm spec file format, how can i escape a % in a spec file, like in ; %define DATE ?date +%s? Release: %{ox_release}.ER.%{DATE} cause it doesn't like the % for the date command. TIA, Erwin From ivazquez at ivazquez.net Sun Feb 19 13:40:01 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 19 Feb 2006 08:40:01 -0500 Subject: spec file question In-Reply-To: <1140356261.17385.336.camel@xpc.home.erwinrol.com> References: <1140356261.17385.336.camel@xpc.home.erwinrol.com> Message-ID: <1140356401.2714.12.camel@ignacio.lan> On Sun, 2006-02-19 at 14:37 +0100, Erwin Rol wrote: > A small question to the rpm spec file format, how can i escape a % in a > spec file, like in ; %% -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mailinglists at erwinrol.com Sun Feb 19 13:45:30 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sun, 19 Feb 2006 14:45:30 +0100 Subject: Questioning Pirut In-Reply-To: <43F85B96.2010006@fedoraproject.org> References: <1140196937.17385.294.camel@xpc.home.erwinrol.com> <43F85B96.2010006@fedoraproject.org> Message-ID: <1140356730.17385.344.camel@xpc.home.erwinrol.com> On Sun, 2006-02-19 at 17:20 +0530, Rahul Sundaram wrote: > Erwin Rol wrote: > >Pirut's GUI is just in a poor pre-alpha state, it hardly follows the > >Gnome HIG, it can't do full screen, strange large font, the GUI > >sometimes locks up when doing "networking" work, and the icons are just > >terrible. If it is going to be shipped in FC5 like this it will just be > >a plain embarrassment for Fedora. > > > I bet that a list of bug reports would be better to a non constructive > flame. Well i think that most of those things are so visible that the developers also know them. And a bug report like "it looks ugly" probably only triggers a "yes we know, we are working on it" reply. If my remark sounded like a flame, I apologize, cause it wasn't meant like that, I just wanted to say that everybody clearly could see Pirut simply isn't ready yet. - Erwin From mailinglists at erwinrol.com Sun Feb 19 13:54:31 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sun, 19 Feb 2006 14:54:31 +0100 Subject: spec file question In-Reply-To: <1140356401.2714.12.camel@ignacio.lan> References: <1140356261.17385.336.camel@xpc.home.erwinrol.com> <1140356401.2714.12.camel@ignacio.lan> Message-ID: <1140357271.17385.349.camel@xpc.home.erwinrol.com> On Sun, 2006-02-19 at 08:40 -0500, Ignacio Vazquez-Abrams wrote: > On Sun, 2006-02-19 at 14:37 +0100, Erwin Rol wrote: > > A small question to the rpm spec file format, how can i escape a % in a > > spec file, like in ; > > %% It seems the problem is not the % but the command just doesn't get executed. So the new question is, how do i excute the date command and put the result in a define like; %define DATE `date +%s` I tried ` ? ' " but non seems to work, the whole string just ends up in the rpm name. - Erwin From sundaram at fedoraproject.org Sun Feb 19 13:55:47 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 19 Feb 2006 19:25:47 +0530 Subject: Questioning Pirut In-Reply-To: <1140356730.17385.344.camel@xpc.home.erwinrol.com> References: <1140196937.17385.294.camel@xpc.home.erwinrol.com> <43F85B96.2010006@fedoraproject.org> <1140356730.17385.344.camel@xpc.home.erwinrol.com> Message-ID: <43F878E3.8050001@fedoraproject.org> Hi >If my remark sounded like a flame, I apologize, cause it wasn't meant >like that, I just wanted to say that everybody clearly could see Pirut >simply isn't ready yet. > >- Erwin > > Then you might cleanly exclude me from that "everybody" list. A utility that knows and understands software repositories is much better for me even with a few IMO minor UI nits. There is no reason for Pirut to follow GNOME HIG. It is a set of guidelines for GNOME applications. Not a set of black and while rules. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From ivazquez at ivazquez.net Sun Feb 19 14:01:28 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 19 Feb 2006 09:01:28 -0500 Subject: spec file question In-Reply-To: <1140357271.17385.349.camel@xpc.home.erwinrol.com> References: <1140356261.17385.336.camel@xpc.home.erwinrol.com> <1140356401.2714.12.camel@ignacio.lan> <1140357271.17385.349.camel@xpc.home.erwinrol.com> Message-ID: <1140357688.2714.14.camel@ignacio.lan> On Sun, 2006-02-19 at 14:54 +0100, Erwin Rol wrote: > So the new question is, how do i excute the date command and put the > result in a define like; > > %define DATE `date +%s` %define DATE %(date +%%s) -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Sun Feb 19 14:05:34 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 19 Feb 2006 19:35:34 +0530 Subject: Questioning Pirut In-Reply-To: <43F6BB9D.6070703@rasmil.dk> References: <43F6BB9D.6070703@rasmil.dk> Message-ID: <43F87B2E.6040509@fedoraproject.org> Hi Tim Lauridsen wrote: > I have suggested to the developers to join forces and get Yum > Extender a.k.a yumex in shape to get into Core. > I takes time to make a good package manager gui and there are no need > to start from scratch. > pup and system-install-packages are in good shape, but pirut need a > lot of work. > The current development release of yumex 0.99.9, currently in > extras-development, is in good shape and works in both > FC4 and rawhide. (and in RHEL 4 (with yum 2.4.x & CentOS 4.2) > > Tim Lauridsen > Yumex Developer. There is nothing called as "system-install-packages". System-config-packages has been replaced by Pirut. Been talking to the relevant developers over this and the design of Pirut is basically to avoid a laundry list of packages and provide a interface that exposes the groups as the primary interface. This is sufficiently different from Yumex to warrant a separate program. A lot of the underlying layers is already shared and we could look into sharing functionality as appropriate. Those who want Yumex can always get it from Fedora Extras. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From mailinglists at erwinrol.com Sun Feb 19 14:09:28 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sun, 19 Feb 2006 15:09:28 +0100 Subject: Questioning Pirut In-Reply-To: <43F878E3.8050001@fedoraproject.org> References: <1140196937.17385.294.camel@xpc.home.erwinrol.com> <43F85B96.2010006@fedoraproject.org> <1140356730.17385.344.camel@xpc.home.erwinrol.com> <43F878E3.8050001@fedoraproject.org> Message-ID: <1140358168.17385.353.camel@xpc.home.erwinrol.com> On Sun, 2006-02-19 at 19:25 +0530, Rahul Sundaram wrote: > Hi > > >If my remark sounded like a flame, I apologize, cause it wasn't meant > >like that, I just wanted to say that everybody clearly could see Pirut > >simply isn't ready yet. > > > >- Erwin > > > > > Then you might cleanly exclude me from that "everybody" list. A utility > that knows and understands software repositories is much better for me > even with a few IMO minor UI nits. There is no reason for Pirut to > follow GNOME HIG. It is a set of guidelines for GNOME applications. Not > a set of black and while rules. Well than we have to agree to differ, and in that case the developer is always right, because No Code, No Vote :-) - Erwin From n0dalus+redhat at gmail.com Sun Feb 19 14:15:31 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Mon, 20 Feb 2006 00:45:31 +1030 Subject: Questioning Pirut In-Reply-To: <43F878E3.8050001@fedoraproject.org> References: <1140196937.17385.294.camel@xpc.home.erwinrol.com> <43F85B96.2010006@fedoraproject.org> <1140356730.17385.344.camel@xpc.home.erwinrol.com> <43F878E3.8050001@fedoraproject.org> Message-ID: <6280325c0602190615h3727868i615a31844c6d4108@mail.gmail.com> On 2/20/06, Rahul Sundaram wrote: > > Then you might cleanly exclude me from that "everybody" list. A utility > that knows and understands software repositories is much better for me > even with a few IMO minor UI nits. There is no reason for Pirut to > follow GNOME HIG. It is a set of guidelines for GNOME applications. Not > a set of black and while rules. > Making some nice icons for it shouldn't be too hard, but there are some other issues with Pirut that are concerning. One is memory usage; last time I looked Pirut used well over 100MB of system memory while doing nothing. I am unable to see if that's improved at the moment because Pirut now crashes with a backtrace on startup (not straight away, it chews up 50MB of system memory first). I strongly agree with Erwin that including this as it is in the final FC5 release could be damaging to Fedora's image. If all the bugs and UI "nits" are patched up before the final release, then I'm sure it will be great. Otherwise, I think we should leave it to FC6 and if necessary include no graphical package manager. My two cents, n0dalus. From sundaram at fedoraproject.org Sun Feb 19 14:29:00 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 19 Feb 2006 19:59:00 +0530 Subject: Questioning Pirut In-Reply-To: <6280325c0602190615h3727868i615a31844c6d4108@mail.gmail.com> References: <1140196937.17385.294.camel@xpc.home.erwinrol.com> <43F85B96.2010006@fedoraproject.org> <1140356730.17385.344.camel@xpc.home.erwinrol.com> <43F878E3.8050001@fedoraproject.org> <6280325c0602190615h3727868i615a31844c6d4108@mail.gmail.com> Message-ID: <43F880AC.606@fedoraproject.org> HI >. > >I strongly agree with Erwin that including this as it is in the final >FC5 release could be damaging to Fedora's image. If all the bugs and >UI "nits" are patched up before the final release. > When you mention bugs, I would immediately like to see them followed by nice informative bug reports. When you mention UI issues, mockups would be great contributions to help in the design of a better UI and while hanging out on #fedora-devel you could always ping and talk to Jeremy and others over their plans for Pirut. Perfectionism is the root of all evils. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From mailinglists at erwinrol.com Sun Feb 19 14:34:46 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sun, 19 Feb 2006 15:34:46 +0100 Subject: spec file question In-Reply-To: <1140357688.2714.14.camel@ignacio.lan> References: <1140356261.17385.336.camel@xpc.home.erwinrol.com> <1140356401.2714.12.camel@ignacio.lan> <1140357271.17385.349.camel@xpc.home.erwinrol.com> <1140357688.2714.14.camel@ignacio.lan> Message-ID: <1140359686.17385.355.camel@xpc.home.erwinrol.com> On Sun, 2006-02-19 at 09:01 -0500, Ignacio Vazquez-Abrams wrote: > On Sun, 2006-02-19 at 14:54 +0100, Erwin Rol wrote: > > So the new question is, how do i excute the date command and put the > > result in a define like; > > > > %define DATE `date +%s` > > %define DATE %(date +%%s) That worked, thanks for the help. Erwin From fcd-cornette at insight.rr.com Sun Feb 19 14:36:26 2006 From: fcd-cornette at insight.rr.com (Jim Cornette) Date: Sun, 19 Feb 2006 09:36:26 -0500 Subject: Questioning Pirut In-Reply-To: <43F878E3.8050001@fedoraproject.org> References: <1140196937.17385.294.camel@xpc.home.erwinrol.com> <43F85B96.2010006@fedoraproject.org> <1140356730.17385.344.camel@xpc.home.erwinrol.com> <43F878E3.8050001@fedoraproject.org> Message-ID: <43F8826A.30905@insight.rr.com> Rahul Sundaram wrote: > Hi > >> If my remark sounded like a flame, I apologize, cause it wasn't meant >> like that, I just wanted to say that everybody clearly could see Pirut >> simply isn't ready yet. >> >> - Erwin >> >> > Then you might cleanly exclude me from that "everybody" list. A utility > that knows and understands software repositories is much better for me > even with a few IMO minor UI nits. There is no reason for Pirut to > follow GNOME HIG. It is a set of guidelines for GNOME applications. Not > a set of black and while rules. > Pirut does look like it is a RHL 7.3 era program by looks. I see nothing wrong with the program appearance on initial usage of the program. I did not even consider anything wrong with the program appearance. The program has not failed me when I used it and the program had decent features. (The list, programs groups and the like.) I do not feel the inclusion within FC5 is an embarrassment and doubt others would feel the program is insufficient either. With my past experience with using programs with a lot of eye candy, actual features were overlooked on my part. My concentration was more into the visual appeal of the program. I am sure that I am not the only person distracted from decor vs. functionality. The program later on could incorporate the eye candy. There might be room for themes and other such add-ons later. It seems there is a desire for the themed approach in some circles. Main course before desert. Jim -- Cahn's Axiom: When all else fails, read the instructions. From wrrhdev at riede.org Sun Feb 19 15:16:36 2006 From: wrrhdev at riede.org (Willem Riede) Date: Sun, 19 Feb 2006 10:16:36 -0500 Subject: Questioning Pirut In-Reply-To: <43F880AC.606@fedoraproject.org> (from sundaram@fedoraproject.org on Sun Feb 19 09:29:00 2006) References: <1140196937.17385.294.camel@xpc.home.erwinrol.com> <43F85B96.2010006@fedoraproject.org> <1140356730.17385.344.camel@xpc.home.erwinrol.com> <43F878E3.8050001@fedoraproject.org> <6280325c0602190615h3727868i615a31844c6d4108@mail.gmail.com> <43F880AC.606@fedoraproject.org> Message-ID: <1140362196l.23688l.3l@athena.riede.org> On 02/19/2006 09:29:00 AM, Rahul Sundaram wrote: > > When you mention bugs, I would immediately like to see them followed bynice > informative bug reports. When you mention UI issues, mockups wouldbe great > contributions to help in the design of a better UI and whilehanging out on > #fedora-devel you could always ping and talk to Jeremyand others over their > plans for Pirut. Perfectionism is the root of allevils. Triggered by this thread, I just tried pirut for the first time, and while it may lack polish, it certainly works. There's two observations that I'll be happy to turn into bugzilla RFEs if so desired: 1. the packages added (or in this case removed) apparently are not added to yum.log - I wish they were; 2. I wish the "details" that you've got 15 seconds to look at contain a list of the packages that are actually going to be added / removed, not just the ones drawn in for dependencies - I removed "dial-up networking", since I'm on cable modem I figured I don't need them, and then saw minicom being erased, which I wanted to keep (but not for dial-up). Easily enough to revert with yum, but I should have been able to avoid it. Thanks, Willem Riede. From sundaram at fedoraproject.org Sun Feb 19 15:20:06 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 19 Feb 2006 20:50:06 +0530 Subject: Questioning Pirut In-Reply-To: <1140362196l.23688l.3l@athena.riede.org> References: <1140196937.17385.294.camel@xpc.home.erwinrol.com> <43F85B96.2010006@fedoraproject.org> <1140356730.17385.344.camel@xpc.home.erwinrol.com> <43F878E3.8050001@fedoraproject.org> <6280325c0602190615h3727868i615a31844c6d4108@mail.gmail.com> <43F880AC.606@fedoraproject.org> <1140362196l.23688l.3l@athena.riede.org> Message-ID: <43F88CA6.5090400@fedoraproject.org> Willem Riede wrote: > On 02/19/2006 09:29:00 AM, Rahul Sundaram wrote: > >> >> When you mention bugs, I would immediately like to see them followed >> bynice informative bug reports. When you mention UI issues, mockups >> wouldbe great contributions to help in the design of a better UI and >> whilehanging out on #fedora-devel you could always ping and talk to >> Jeremyand others over their plans for Pirut. Perfectionism is the >> root of allevils. > > > Triggered by this thread, I just tried pirut for the first time, and > while it may lack polish, it certainly works. There's two > observations that I'll be happy to turn into bugzilla RFEs if so > desired: > > 1. the packages added (or in this case removed) apparently are not > added to yum.log - I wish they were; > 2. I wish the "details" that you've got 15 seconds to look at contain > a list of the packages that are actually going to be added / removed, > not just the ones drawn in for dependencies - I removed "dial-up > networking", since I'm on cable modem I figured I don't need them, > and then saw minicom being erased, which I wanted to keep (but not > for dial-up). Easily enough to revert with yum, but I should have > been able to avoid it. Ya. Go ahead and file those as enhancement requests. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From igorm5 at vip.hr Sun Feb 19 15:20:49 2006 From: igorm5 at vip.hr (Igor) Date: Sun, 19 Feb 2006 16:20:49 +0100 Subject: Questioning Pirut In-Reply-To: <43F85B5D.50309@fedoraproject.org> References: <43F85B5D.50309@fedoraproject.org> Message-ID: <43F88CD1.7010302@vip.hr> Rahul Sundaram ka?e: > Kevin Verma wrote: >>Dear Pirut Developers, >>I've been trying to use Pirut over the FC5 rawhide, referring a screen >>shot here from the wiki, >>http://fedoraproject.org/wiki/Tours/FedoraCore5/007_Pirut >>I will like to know your point of view why we really needed yet >>another package manager, I understand that this one is created more to >>adapt to Yum system. I will like to know your view if >>system-config-packages could have been adapted to Yum as well ? > That is exactly what pirut is. A adoption of system-config-packages to > use a yum backend with a new name to reflect the fact that the tool > doesnt require any configuration. But there is a thing I don't like with Pirut. Pirut will always look on the internet first, instead of looking into the CD/DVD media. That's a feature which dial-up users won't like very much. The system-config-packages tool worked only with CD/DVD media, which is much better approach for dial-up users. All the users who have fast connection to internet can always use Yum or Yumex for installing new packages. -- Igor Jagec From jspaleta at gmail.com Sun Feb 19 15:37:10 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 19 Feb 2006 10:37:10 -0500 Subject: Questioning Pirut In-Reply-To: <43F88CD1.7010302@vip.hr> References: <43F85B5D.50309@fedoraproject.org> <43F88CD1.7010302@vip.hr> Message-ID: <604aa7910602190737l491be5a9k8d4b56c9d6323861@mail.gmail.com> On 2/19/06, Igor wrote: > But there is a thing I don't like with Pirut. Pirut will always look on > the internet first, instead of looking into the CD/DVD media. File it, I'm sure there is room for improvement to to make this tool more useful for dial-up users. It might be as simple as exposing a switch in gui preferences to control media search on initialization. The fact that it looks at botth cd media and the internet..at all.. is the big change. Fine tuning how that works so people can use the local media effectively is certaintly not over. > That's a > feature which dial-up users won't like very much. The > system-config-packages tool worked only with CD/DVD media, which is much > better approach for dial-up users. The old approach had very bad limitations... even for dialup users...once you had any updates installed (which were not available on the original medium) it was nearly impossible to use the tool again because of dependancy mismatches. -jef From brunson at brunson.com Sun Feb 19 17:48:00 2006 From: brunson at brunson.com (Eric Brunson) Date: Sun, 19 Feb 2006 10:48:00 -0700 Subject: Please disable the SELinux execstack/relro checks before FC5 final In-Reply-To: <43F68B1B.5080002@redhat.com> References: <1140172961.2980.29.camel@laptopd505.fenrus.org> <1140186395.12655.245.camel@moss-spartans.epoch.ncsc.mil> <1140187398.12655.259.camel@moss-spartans.epoch.ncsc.mil> <1140207269.2980.57.camel@laptopd505.fenrus.org> <43F68B1B.5080002@redhat.com> Message-ID: <43F8AF50.4010400@brunson.com> Ulrich Drepper wrote: > Arjan van de Ven wrote: > >> right now I fear the only sane answer is "set all to permissive >> behavior"; the minimum for fc5 would be everything that can do plugins >> of any kind, or uses libraries that tend to get replaced (3D ones ;). >> But that ends up being a whole whopping lot... >> > > I'm not so sure. > > The most crappy software are all those mozilla/firefox/thunderbird > plugins. So, yes, we might need more time for that although I'd rather > prefer to have a separate domain for those programs. > > The NVidia driver also needs an executable stack but nothing else. > > What I have not seen are programs which have their own domain and still > need any of the booleans set. Somebody should show real evidence that > any of those domains need the permission checks disable. > > If we cannot move the moz/ffox/tbird into their own domain then, yes, > disable the checks for unconfined processes. But we should keep the > tests for all programs which have their own domain. > > This NVidia driver issue seems to be cropping up a lot on the forums. Is there a fix for it other than setting permissive globally? From drepper at redhat.com Sun Feb 19 18:01:58 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Sun, 19 Feb 2006 10:01:58 -0800 Subject: Please disable the SELinux execstack/relro checks before FC5 final In-Reply-To: <43F8AF50.4010400@brunson.com> References: <1140172961.2980.29.camel@laptopd505.fenrus.org> <1140186395.12655.245.camel@moss-spartans.epoch.ncsc.mil> <1140187398.12655.259.camel@moss-spartans.epoch.ncsc.mil> <1140207269.2980.57.camel@laptopd505.fenrus.org> <43F68B1B.5080002@redhat.com> <43F8AF50.4010400@brunson.com> Message-ID: <43F8B296.5020807@redhat.com> Eric Brunson wrote: > This NVidia driver issue seems to be cropping up a lot on the forums. > Is there a fix for it other than setting permissive globally? Has anybody ever tried to simply reset the flag? Use execstack -c /usr/lib*/libGL.so If you want, make a copy of the file first. But it should also be possible to use execstack -s /usr/lib*/libGL.so to undo the effect. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From ivg2 at cornell.edu Sun Feb 19 18:20:40 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Sun, 19 Feb 2006 13:20:40 -0500 Subject: Please disable the SELinux execstack/relro checks before FC5 final In-Reply-To: <43F68B1B.5080002@redhat.com> References: <1140172961.2980.29.camel@laptopd505.fenrus.org> <1140186395.12655.245.camel@moss-spartans.epoch.ncsc.mil> <1140187398.12655.259.camel@moss-spartans.epoch.ncsc.mil> <1140207269.2980.57.camel@laptopd505.fenrus.org> <43F68B1B.5080002@redhat.com> Message-ID: <43F8B6F8.20304@cornell.edu> > If we cannot move the moz/ffox/tbird into their own domain then, yes, > disable the checks for unconfined processes. But we should keep the > tests for all programs which have their own domain. > Moz/ffox/tbird cannot be moved into their own domain until we have the capability to launch content handling applications from within firefox, and have them enter the proper domain. This is particularly difficult, because some of those applications (i.e. openoffice) don't have a domain at the moment (and creating one would be difficult). That means firefox must be allowed to transition into user_t/unconfined_t, which defeats any attempt at security. Launching one application within another is the primary reason why the desktop can't be confined. In the old strict policy firefox and mozilla were confined, and I worked on the evolution and thunderbird policies over the summer. I think the basic functionality was working, but those programs could not be allowed to launch other apps. We need a trusted program to be responsible for that, so that firefox can't transition into the generic domain. There's other problems as well, including limiting those programs' ability to write to the user home directory, and the top level /tmp directory (what good does confining an application do, if it can still overwrite all your important files, or steal your credit card info?). There's marking of content as potentially hostile, and management of that content. There's an effort to limit bonobo connections from firefox to restricted domains only (no user_t/unconfined_t connections).... also challenging, because there's so many things firefox talks to, and one of them is sufficient to necessitate allowing communications channel to user_t/unconfined_t. ============= Currently the firefox/moz/tbird/evolution policies have not been ported yet to the new refpolicy. They also require the policies for bonobo, orbit, gnome and other dekstop-related things (also not yet ported). Even when they are ported, I doubt they would meet the needs of targeted-policy users. From ivg2 at cornell.edu Sun Feb 19 18:37:01 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Sun, 19 Feb 2006 13:37:01 -0500 Subject: Please disable the SELinux execstack/relro checks before FC5 final In-Reply-To: <43F8B6F8.20304@cornell.edu> References: <1140172961.2980.29.camel@laptopd505.fenrus.org> <1140186395.12655.245.camel@moss-spartans.epoch.ncsc.mil> <1140187398.12655.259.camel@moss-spartans.epoch.ncsc.mil> <1140207269.2980.57.camel@laptopd505.fenrus.org> <43F68B1B.5080002@redhat.com> <43F8B6F8.20304@cornell.edu> Message-ID: <43F8BACD.7000201@cornell.edu> > > There's an effort to limit bonobo connections from firefox to > restricted domains only (no user_t/unconfined_t connections).... also > challenging, because there's so many things firefox talks to, and one > of them is sufficient to necessitate allowing communications channel > to user_t/unconfined_t. Isn't bonobo capable of doing exactly what we need anyway - launching applications based on required characteristics sent over a socket to its server? Maybe I'm ignorant of how those things work, but having a centralized way to launch other apps (from a different process than our own) would be very helpful to selinux. From igorm5 at vip.hr Sun Feb 19 18:52:25 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Sun, 19 Feb 2006 19:52:25 +0100 Subject: Questioning Pirut In-Reply-To: <604aa7910602190737l491be5a9k8d4b56c9d6323861@mail.gmail.com> References: <43F85B5D.50309@fedoraproject.org> <43F88CD1.7010302@vip.hr> <604aa7910602190737l491be5a9k8d4b56c9d6323861@mail.gmail.com> Message-ID: <43F8BE69.1050004@vip.hr> Jeff Spaleta ka?e: > On 2/19/06, Igor wrote: >>But there is a thing I don't like with Pirut. Pirut will always look on >>the internet first, instead of looking into the CD/DVD media. > File it, I'm sure there is room for improvement to to make this tool >From Red Hat's bugzilla: Invalid Product Name The product name '' is invalid or does not exist. Please press Back and try again. --------- Bug Information Reporter igorm5 at vip.hr Product Fedora Core --------- Is that a bug in bugzilla or "Fedora Core" product name does not exist? > more useful for dial-up users. It might be as simple as exposing a > switch in gui preferences to control media search on initialization. > The fact that it looks at botth cd media and the internet..at all.. is > the big change. Fine tuning how that works so people can use the local > media effectively is certaintly not over. Yep, You've got the point. That fine tuning would be highly appreciated. >>That's a >>feature which dial-up users won't like very much. The >>system-config-packages tool worked only with CD/DVD media, which is much >>better approach for dial-up users. > The old approach had very bad limitations... even for dialup > users...once you had any updates installed (which were not available > on the original medium) it was nearly impossible to use the tool again > because of dependancy mismatches. Yep, you're right, but I was not saying that system-config-packages was better than Pirut (It was definitely not), but has that feature itself. Pirut will be much better with that media switch, or something. Cheers! -- Igor Jagec From fcd-cornette at insight.rr.com Sun Feb 19 19:17:17 2006 From: fcd-cornette at insight.rr.com (Jim Cornette) Date: Sun, 19 Feb 2006 14:17:17 -0500 Subject: Please disable the SELinux execstack/relro checks before FC5 final In-Reply-To: <43F8B296.5020807@redhat.com> References: <1140172961.2980.29.camel@laptopd505.fenrus.org> <1140186395.12655.245.camel@moss-spartans.epoch.ncsc.mil> <1140187398.12655.259.camel@moss-spartans.epoch.ncsc.mil> <1140207269.2980.57.camel@laptopd505.fenrus.org> <43F68B1B.5080002@redhat.com> <43F8AF50.4010400@brunson.com> <43F8B296.5020807@redhat.com> Message-ID: <43F8C43D.8000405@insight.rr.com> Ulrich Drepper wrote: > Eric Brunson wrote: >> This NVidia driver issue seems to be cropping up a lot on the forums. >> Is there a fix for it other than setting permissive globally? > > Has anybody ever tried to simply reset the flag? Use > > execstack -c /usr/lib*/libGL.so > > If you want, make a copy of the file first. But it should also be > possible to use > > execstack -s /usr/lib*/libGL.so > > to undo the effect. > > The problem happens with fedora-extras programs also. Ppracer would not start before execstack -s was performed on the library. I ra ppracer ppracer: error while loading shared libraries: libGL.so.1: cannot enable executable stack as shared object requires: Permission denied [jim at cornette-lt ~]$ locate libGL.so.1 /usr/lib/libGL.so.1 /usr/lib/libGL.so.1.2 execstack -c /usr/lib/libGL.so.1 allowed ppracer to start. The performance was pretty poor though with a radeon and oss driver. Section "Device" Identifier "Videocard0" Driver "radeon" VendorName "Videocard vendor" BoardName "ATI Technologies Inc Radeon Mobility U1" I take it that there are many more instances around. Thanks for the hint. Jim From nman64 at n-man.com Sun Feb 19 19:39:13 2006 From: nman64 at n-man.com (Patrick Barnes) Date: Sun, 19 Feb 2006 13:39:13 -0600 Subject: [ANN] Fedora Project Wiki Policy Change (Update) In-Reply-To: <200602161806.29490.nman64@n-man.com> References: <200602161806.29490.nman64@n-man.com> Message-ID: <200602191339.15904.nman64@n-man.com> We have completed the shift to our new wiki policy. The Contributor License Agreement is now required for wiki editing privileges. The EditGroup[1] is no longer frozen. EditGroup members who have already completed the CLA do not need to do anything. They should be able to continue editing normally. All former EditGroup members who have not completed the CLA have been moved to the new UnlicensedGroup[2] page. They will be unable to edit the wiki until they have completed the CLA and have removed themselves from the UnlicensedGroup. Once they have done so, they can contact someone currently on the EditGroup to get themselves added again. More details about these changes can be found on the WikiLicenseTalk[3] page. As always, wiki editing details can be found on the WikiEditing[4] page. [1] http://fedoraproject.org/wiki/EditGroup [2] http://fedoraproject.org/wiki/UnlicensedGroup [3] http://fedoraproject.org/wiki/WikiLicenseTalk [4] http://fedoraproject.org/wiki/WikiEditing -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ivg2 at cornell.edu Sun Feb 19 20:14:47 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Sun, 19 Feb 2006 15:14:47 -0500 Subject: Please disable the SELinux execstack/relro checks before FC5 final In-Reply-To: <43F8C43D.8000405@insight.rr.com> References: <1140172961.2980.29.camel@laptopd505.fenrus.org> <1140186395.12655.245.camel@moss-spartans.epoch.ncsc.mil> <1140187398.12655.259.camel@moss-spartans.epoch.ncsc.mil> <1140207269.2980.57.camel@laptopd505.fenrus.org> <43F68B1B.5080002@redhat.com> <43F8AF50.4010400@brunson.com> <43F8B296.5020807@redhat.com> <43F8C43D.8000405@insight.rr.com> Message-ID: <43F8D1B7.2030504@cornell.edu> >>> This NVidia driver issue seems to be cropping up a lot on the >>> forums. Is there a fix for it other than setting permissive globally? >> >> Has anybody ever tried to simply reset the flag? Use >> >> execstack -c /usr/lib*/libGL.so This thread is totally confusing me.... I haven't been following exactly what's going on with this problem, but: - /usr/lib*/libGL.so.1 is the Mesa GL library - /usr/lib*/nvidia/libGL.so.1 is the Nvidia GL library, when properly installed via livna On my computer both are marked GNU_STACK RWE, which seems relevant to this problem (correct me if that's not true), so I'm not sure why Nvidia is being blamed, and Mesa is not. This is x86_64. - I get denials attempting to execute /dev/zero, exectstack, and execmem for glxgears with the Nvidia driver. - I tried testing with the nv driver, but it crashed after I restarted X a few times, so I think selinux is not the primary problem when it comes to this driver. I'm running back to the "stable" nvidia driver [ even though it crashes on suspend ] :) Will do more testing, but the point is that it's not clear which libGL library is causing the problem from this thread. > [jim at cornette-lt ~]$ locate libGL.so.1 > /usr/lib/libGL.so.1 > /usr/lib/libGL.so.1.2 Doesn't this indicate the Mesa libGL library, and not the Nvidia or ATI one? > I take it that there are many more instances around. > Yes, I would expect to see problems with binaries that link to libGL... From arjan at fenrus.demon.nl Sun Feb 19 20:00:39 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sun, 19 Feb 2006 21:00:39 +0100 Subject: Please disable the SELinux execstack/relro checks before FC5 final In-Reply-To: <43F8C43D.8000405@insight.rr.com> References: <1140172961.2980.29.camel@laptopd505.fenrus.org> <1140186395.12655.245.camel@moss-spartans.epoch.ncsc.mil> <1140187398.12655.259.camel@moss-spartans.epoch.ncsc.mil> <1140207269.2980.57.camel@laptopd505.fenrus.org> <43F68B1B.5080002@redhat.com> <43F8AF50.4010400@brunson.com> <43F8B296.5020807@redhat.com> <43F8C43D.8000405@insight.rr.com> Message-ID: <1140379240.6514.36.camel@laptopd505.fenrus.org> > > The problem happens with fedora-extras programs also. Ppracer would not > start before execstack -s was performed on the library. The fedora library or the ATI binary one ? From cmadams at hiwaay.net Sun Feb 19 22:57:47 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Sun, 19 Feb 2006 16:57:47 -0600 Subject: Please disable the SELinux execstack/relro checks before FC5 final In-Reply-To: <1140379240.6514.36.camel@laptopd505.fenrus.org> References: <1140172961.2980.29.camel@laptopd505.fenrus.org> <1140186395.12655.245.camel@moss-spartans.epoch.ncsc.mil> <1140187398.12655.259.camel@moss-spartans.epoch.ncsc.mil> <1140207269.2980.57.camel@laptopd505.fenrus.org> <43F68B1B.5080002@redhat.com> <43F8AF50.4010400@brunson.com> <43F8B296.5020807@redhat.com> <43F8C43D.8000405@insight.rr.com> <1140379240.6514.36.camel@laptopd505.fenrus.org> Message-ID: <20060219225747.GC568161@hiwaay.net> Once upon a time, Arjan van de Ven said: > > The problem happens with fedora-extras programs also. Ppracer would not > > start before execstack -s was performed on the library. > > The fedora library or the ATI binary one ? I get that with a straight Fedora install. Do a basic install and then "yum install ppracer", and ppracer will fail to start. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From mailinglists at erwinrol.com Sun Feb 19 23:33:59 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Mon, 20 Feb 2006 00:33:59 +0100 Subject: Open Xchange for FC5 with GCJ 4.1 Message-ID: <1140392039.17385.390.camel@xpc.home.erwinrol.com> Hey all, I uploaded two SRPM files for FC5 (Fedora Core 5 AKA Rawhide). Before you even download those files take note of the following; 1) Do _NOT_ bother the Open Xchange developers with bugs/errors/problems found in those SRPM's, contact me instead. 2) Do _NOT_ file bug reports in OX bugzilla for bugs you find in those SRPM's, contact me instead. 3) Do _NOT_ use those SRPM's on a production system, they might destroy, your postgresql, openldap, tomcat and httpd setup. 4) It is highly unlikely that those SRPM's work on anything else but FC5 with GCJ 4.1. Now to what i have done, first of all I needed a CVS version of gnu javamail. That version can be found here; http://www.erwinrol.com/downloads/software/ox_javamail-1.3.0-1.CVS20060218.src.rpm As you can see the name is different from the default name, this is to make it possible to keep your original javamail jar files, so other programs do not break. Build and install this RPM first. Than you can download the Open Xchange RPM; http://www.erwinrol.com/downloads/software/open-xchange-0.8.2-RC3.ER.20060219234052.src.rpm Building that RPM should work, but it might be missing a bunch of Dependencies and so you might run into trouble, if that happens please report the missing dependencies to me. Before building the SRPM change the passwords in the spec file. the files to setup LDAP and Postgres might not work, it would be best to test it against a known good LDAP and postgres setup, that way you don't hunt bugs that are just setup errors. The RPM holds a 500k patch, so you can see it changes a lot, and surely breaks things too. The way i worked was, simply move from exception to exception. Play around a bit with it, and than look in the log files for exceptions, and than fix those. That is a lot of work but it isn't even that complicated, although the OX source code is not very well documented and so understanding what it should do is not always easy. Of course not everything works, but database access seems to work now with postgresql 8.1 (both server and jdbc). Webmail also seems to be able to read mail. And I can login, so Ldap also kind of works. I think ldap addressbook is still a problem, but that is because the ldap part is a serious hack, the imap stuff also has some hanks. Since I have a busy week coming up I will continue with the development next weekend, I hope some ppl could play around with it in the meanwhile and report all problems to me, so I can fix them next weekend. - Erwin From drepper at redhat.com Mon Feb 20 01:23:00 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Sun, 19 Feb 2006 17:23:00 -0800 Subject: Please disable the SELinux execstack/relro checks before FC5 final In-Reply-To: <43F8C43D.8000405@insight.rr.com> References: <1140172961.2980.29.camel@laptopd505.fenrus.org> <1140186395.12655.245.camel@moss-spartans.epoch.ncsc.mil> <1140187398.12655.259.camel@moss-spartans.epoch.ncsc.mil> <1140207269.2980.57.camel@laptopd505.fenrus.org> <43F68B1B.5080002@redhat.com> <43F8AF50.4010400@brunson.com> <43F8B296.5020807@redhat.com> <43F8C43D.8000405@insight.rr.com> Message-ID: <43F919F4.10103@redhat.com> Jim Cornette wrote: > execstack -c /usr/lib/libGL.so.1 allowed ppracer to start. The > performance was pretty poor though with a radeon and oss driver. Let's not confuse things. You say that wafter fixing up the NVidia driver with execstack -c it works? The same as it would after disabling enforcement? That's the only thing important here. Whether there are other problems re speed etc should be brought up separately. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From drepper at redhat.com Mon Feb 20 01:28:40 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Sun, 19 Feb 2006 17:28:40 -0800 Subject: Please disable the SELinux execstack/relro checks before FC5 final In-Reply-To: <43F8D1B7.2030504@cornell.edu> References: <1140172961.2980.29.camel@laptopd505.fenrus.org> <1140186395.12655.245.camel@moss-spartans.epoch.ncsc.mil> <1140187398.12655.259.camel@moss-spartans.epoch.ncsc.mil> <1140207269.2980.57.camel@laptopd505.fenrus.org> <43F68B1B.5080002@redhat.com> <43F8AF50.4010400@brunson.com> <43F8B296.5020807@redhat.com> <43F8C43D.8000405@insight.rr.com> <43F8D1B7.2030504@cornell.edu> Message-ID: <43F91B48.5040202@redhat.com> Ivan Gyurdiev wrote: >>> execstack -c /usr/lib*/libGL.so > This thread is totally confusing me.... > I haven't been following exactly what's going on with this problem, but: > - /usr/lib*/libGL.so.1 is the Mesa GL library > - /usr/lib*/nvidia/libGL.so.1 is the Nvidia GL library, when properly > installed via livna > > On my computer both are marked GNU_STACK RWE, which seems relevant to > this problem (correct me if that's not true), so I'm not sure why Nvidia > is being blamed, and Mesa is not. This is x86_64. Don't assume the filesystem layout is the same on all machines. For me, the /usr/lib*/libGL.so files are the NVidia files. This is why I mentioned the command line above. Whether the Mesa libraries have the same issue is another issue which somebody might want to investigate. I think what follows from the results I"ve seen so far is that it is only a build problem on the NVidia driver's side that the E bit is set and that it is safe to clear the bit using the execstack command. > - I get denials attempting to execute /dev/zero, exectstack, and execmem > for glxgears with the Nvidia driver. Do you have the DSO marked with textrel_shlib_t? That'll always be necessary. Look at the driver: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x0000003fe9900000 0x0000003fe9900000 0x081258 0x081258 R E 0x100000 LOAD 0x081260 0x0000003fe9a81260 0x0000003fe9a81260 0x02fda0 0x0318c0 RWE 0x100000 DYNAMIC 0x0b02b8 0x0000003fe9ab02b8 0x0000003fe9ab02b8 0x000200 0x000200 RW 0x8 GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RWE 0x8 Section to Segment mapping: Segment Sections... 00 [RO: .hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .plt .text .rodata] 01 .data .writetext .eh_frame .dynamic .got .bss 02 .dynamic 03 They deliberately create a text section which is writable (.data.writetext). That segment must be writable. > Will do more testing, but the point is that it's not clear which libGL > library is causing the problem from this thread. >> [jim at cornette-lt ~]$ locate libGL.so.1 >> /usr/lib/libGL.so.1 >> /usr/lib/libGL.so.1.2 > Doesn't this indicate the Mesa libGL library, and not the Nvidia or ATI > one? That completely depends on how things are installed on your machine. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From drepper at redhat.com Mon Feb 20 01:29:51 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Sun, 19 Feb 2006 17:29:51 -0800 Subject: Please disable the SELinux execstack/relro checks before FC5 final In-Reply-To: <20060219225747.GC568161@hiwaay.net> References: <1140172961.2980.29.camel@laptopd505.fenrus.org> <1140186395.12655.245.camel@moss-spartans.epoch.ncsc.mil> <1140187398.12655.259.camel@moss-spartans.epoch.ncsc.mil> <1140207269.2980.57.camel@laptopd505.fenrus.org> <43F68B1B.5080002@redhat.com> <43F8AF50.4010400@brunson.com> <43F8B296.5020807@redhat.com> <43F8C43D.8000405@insight.rr.com> <1140379240.6514.36.camel@laptopd505.fenrus.org> <20060219225747.GC568161@hiwaay.net> Message-ID: <43F91B8F.7070804@redhat.com> Chris Adams wrote: > I get that with a straight Fedora install. Do a basic install and then > "yum install ppracer", and ppracer will fail to start. This doesn't say anything. How does it fail? What DSOs are loaded? How do the DSOs look like (output of eu-readelf -l DSO). -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From cmadams at hiwaay.net Mon Feb 20 01:41:58 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Sun, 19 Feb 2006 19:41:58 -0600 Subject: Please disable the SELinux execstack/relro checks before FC5 final In-Reply-To: <43F91B8F.7070804@redhat.com> References: <1140186395.12655.245.camel@moss-spartans.epoch.ncsc.mil> <1140187398.12655.259.camel@moss-spartans.epoch.ncsc.mil> <1140207269.2980.57.camel@laptopd505.fenrus.org> <43F68B1B.5080002@redhat.com> <43F8AF50.4010400@brunson.com> <43F8B296.5020807@redhat.com> <43F8C43D.8000405@insight.rr.com> <1140379240.6514.36.camel@laptopd505.fenrus.org> <20060219225747.GC568161@hiwaay.net> <43F91B8F.7070804@redhat.com> Message-ID: <20060220014158.GB831604@hiwaay.net> Once upon a time, Ulrich Drepper said: > Chris Adams wrote: > > I get that with a straight Fedora install. Do a basic install and then > > "yum install ppracer", and ppracer will fail to start. > > This doesn't say anything. How does it fail? What DSOs are loaded? > How do the DSOs look like (output of eu-readelf -l DSO). Well, it had resulted in an exec stack error on libGL (last tried a week or so ago IIRC). However, with a up to date devel (Core and Extras) system, ppracer starts now. You can see the message that did result a couple messages up this thread: https://www.redhat.com/archives/fedora-devel-list/2006-February/msg00919.html Checking, my system seems to show libGL.so.1.2 marked for execstack on install now: $ execstack -q /usr/lib/libGL.so.1.2 X /usr/lib/libGL.so.1.2 I'm pretty sure I didn't set it that way (on this install). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From ivg2 at cornell.edu Mon Feb 20 03:11:15 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Sun, 19 Feb 2006 22:11:15 -0500 Subject: Please disable the SELinux execstack/relro checks before FC5 final In-Reply-To: <43F91B48.5040202@redhat.com> References: <1140172961.2980.29.camel@laptopd505.fenrus.org> <1140186395.12655.245.camel@moss-spartans.epoch.ncsc.mil> <1140187398.12655.259.camel@moss-spartans.epoch.ncsc.mil> <1140207269.2980.57.camel@laptopd505.fenrus.org> <43F68B1B.5080002@redhat.com> <43F8AF50.4010400@brunson.com> <43F8B296.5020807@redhat.com> <43F8C43D.8000405@insight.rr.com> <43F8D1B7.2030504@cornell.edu> <43F91B48.5040202@redhat.com> Message-ID: <43F93353.7030609@cornell.edu> >> - I get denials attempting to execute /dev/zero, exectstack, and execmem >> for glxgears with the Nvidia driver. >> > > Do you have the DSO marked with textrel_shlib_t? That'll always be > necessary. Look at the driver: > > Yes, both my Mesa libGL and the nvidia one are marked textrel_shlib_t. Marking things textrel_shlib_t has no effect on execstack/execmem - it only suppresses execmod denials. Actually I seem to get a different error than the other posters in enforcing mode: glxgears: error while loading shared libraries: libGL.so.1: failed to map segment from shared object: Permission denied This is strict policy btw, it's rather broken... >>> [jim at cornette-lt ~]$ locate libGL.so.1 >>> /usr/lib/libGL.so.1 >>> /usr/lib/libGL.so.1.2 >>> >> Doesn't this indicate the Mesa libGL library, and not the Nvidia or ATI >> one? >> > > That completely depends on how things are installed on your machine. > The version numbering indicate likely Mesa libGL. The poster mentioned oss drivers, and radeon card. I find it highly unlikely you are talking about the same thing. From dlutter at redhat.com Mon Feb 20 03:35:34 2006 From: dlutter at redhat.com (David Lutterkort) Date: Sun, 19 Feb 2006 19:35:34 -0800 Subject: OpenLDAP config update from RPM In-Reply-To: <1140221788.17385.302.camel@xpc.home.erwinrol.com> References: <1140129969.17385.246.camel@xpc.home.erwinrol.com> <1140187381.15963.2.camel@dhollis-lnx.sunera.com> <1140221788.17385.302.camel@xpc.home.erwinrol.com> Message-ID: <1140406535.5240.5.camel@currant.watzmann.net> On Sat, 2006-02-18 at 01:16 +0100, Erwin Rol wrote: > That is what i did now, because i saw some other RPM's that used "patch" > to change system config files like postgres, openldap and httpd/tomcat ^^^^^^^^ Do you remember which packages dealt with postgres that way ? David From fcd-cornette at insight.rr.com Mon Feb 20 03:39:12 2006 From: fcd-cornette at insight.rr.com (Jim Cornette) Date: Sun, 19 Feb 2006 22:39:12 -0500 Subject: Please disable the SELinux execstack/relro checks before FC5 final In-Reply-To: <1140379240.6514.36.camel@laptopd505.fenrus.org> References: <1140172961.2980.29.camel@laptopd505.fenrus.org> <1140186395.12655.245.camel@moss-spartans.epoch.ncsc.mil> <1140187398.12655.259.camel@moss-spartans.epoch.ncsc.mil> <1140207269.2980.57.camel@laptopd505.fenrus.org> <43F68B1B.5080002@redhat.com> <43F8AF50.4010400@brunson.com> <43F8B296.5020807@redhat.com> <43F8C43D.8000405@insight.rr.com> <1140379240.6514.36.camel@laptopd505.fenrus.org> Message-ID: <43F939E0.4080700@insight.rr.com> Arjan van de Ven wrote: >> The problem happens with fedora-extras programs also. Ppracer would not >> start before execstack -s was performed on the library. > > The fedora library or the ATI binary one ? > > The Fedora Library and not the ATI binary. (3D does not work well at all.) The ppracer game worked recently when I let a child play the game before the massive rebuild. I don't know exactly when it quit working Before performing execstack -c /usr/lib/libGL.so.1 ppcracer would error out and not launch. I have mesa-libGL-6.4.2-2.1 installed and it verifies with rpm. Jim From david.spudich at elmarco.cz Mon Feb 20 07:32:31 2006 From: david.spudich at elmarco.cz (david.spudich at elmarco.cz) Date: Mon, 20 Feb 2006 08:32:31 +0100 Subject: David Spudich is out of the office. Message-ID: I will be out of the office starting 20.02.2006 and will not return until 21.02.2006. TEST, I`m still at my office. David From paul at city-fan.org Mon Feb 20 07:37:41 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 20 Feb 2006 07:37:41 +0000 Subject: Yum and SRPMs In-Reply-To: <1140274991.2211.11.camel@athlon2000> References: <1133079326.2854.1.camel@entropy> <20051128124649.GB29992@jadzia.bu.edu> <1133185654.21208.124.camel@cutter> <6280325c0511280703v2c514df8p63c31ca9cf06def7@mail.gmail.com> <1133190580.6952.0.camel@cutter> <604aa7910511280719l59f4921bja4c15e160cfb4e77@mail.gmail.com> <1133195955.16284.1.camel@weasel.turre.laiskiainen.org> <604aa7910511280856g3f043934g4c7da09e83ed181a@mail.gmail.com> <1140126778.2437.23.camel@ender> <1140274991.2211.11.camel@athlon2000> Message-ID: <1140421061.11256.15.camel@laurel.intra.city-fan.org> On Sat, 2006-02-18 at 10:03 -0500, William Lovaton wrote: > Hi, > > El jue, 16-02-2006 a las 13:52 -0800, Jesse Keating escribi?: > > I made a small mistake. The unified SRPMS and srpm repodata will be > > useful for yumdownloader, not yum itself. Yum does not and will not > > have the ability to grab srpms. > > yumdownloader? I hope it is what I am thinking. > > You'll see, my home computer is connected to the Internet through a > modem and most of the time making updates is prohibited because more > often that not they are very large, so I religiously copy the packages > names that needs an update, I take them to my office and wget them from > a very fast connection one by one into my usb memory and finally back to > my home and copy the packages in the yum cache. > > Is there a way to make the downloading part of this automatic? something > like yum generating all the wget commands so I can use them on a very > fast connection easily instead of one by one. yumdownloader has a "--urls" option that will give you the URLs to download. This could easily be scripted into a bunch of wget commands. Paul. From buildsys at redhat.com Mon Feb 20 08:21:09 2006 From: buildsys at redhat.com (Build System) Date: Mon, 20 Feb 2006 03:21:09 -0500 Subject: rawhide report: 20060220 changes Message-ID: <200602200821.k1K8L9Zf008789@porkchop.devel.redhat.com> Updated Packages: (none) Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs vconfig - 1.9-1.1.ia64 requires libc.so.6 vconfig - 1.9-1.1.ia64 requires libc.so.6(GLIBC_2.0) Broken deps for ppc64 ---------------------------------------------------------- emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi vconfig - 1.9-1.1.ppc64 requires libc.so.6 vconfig - 1.9-1.1.ppc64 requires libc.so.6(GLIBC_2.0) Broken deps for s390 ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 Broken deps for s390x ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) From mailinglists at erwinrol.com Mon Feb 20 08:27:10 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Mon, 20 Feb 2006 09:27:10 +0100 Subject: OpenLDAP config update from RPM In-Reply-To: <1140406535.5240.5.camel@currant.watzmann.net> References: <1140129969.17385.246.camel@xpc.home.erwinrol.com> <1140187381.15963.2.camel@dhollis-lnx.sunera.com> <1140221788.17385.302.camel@xpc.home.erwinrol.com> <1140406535.5240.5.camel@currant.watzmann.net> Message-ID: <1140424030.29378.4.camel@xpc.home.erwinrol.com> On Sun, 2006-02-19 at 19:35 -0800, David Lutterkort wrote: > On Sat, 2006-02-18 at 01:16 +0100, Erwin Rol wrote: > > That is what i did now, because i saw some other RPM's that used "patch" > > to change system config files like postgres, openldap and httpd/tomcat > ^^^^^^^^ > > Do you remember which packages dealt with postgres that way ? Those "other RPM's" were some Open Xchange RPM's I found on the net, nothing official. -Erwin From che666 at gmail.com Mon Feb 20 09:09:45 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Mon, 20 Feb 2006 10:09:45 +0100 Subject: Yum and SRPMs In-Reply-To: <1140126778.2437.23.camel@ender> References: <1133079326.2854.1.camel@entropy> <20051128124649.GB29992@jadzia.bu.edu> <1133185654.21208.124.camel@cutter> <6280325c0511280703v2c514df8p63c31ca9cf06def7@mail.gmail.com> <1133190580.6952.0.camel@cutter> <604aa7910511280719l59f4921bja4c15e160cfb4e77@mail.gmail.com> <1133195955.16284.1.camel@weasel.turre.laiskiainen.org> <604aa7910511280856g3f043934g4c7da09e83ed181a@mail.gmail.com> <1140126778.2437.23.camel@ender> Message-ID: 2006/2/16, Jesse Keating : > On Thu, 2006-02-16 at 16:36 -0500, Sadda Teh wrote: > > > > My current perception of being able to develop software that's part of > > the Fedora environment means one needs intimate knowledge of RPM and > > its various spin off utilities. At least now it seems like a > > user-friendly tool like yum is going to assist in actually getting the > > SRPMs onto one's machine. Can Jesse or someone else expand on what > > this new feature really means if my impression is totally off-base? > > I made a small mistake. The unified SRPMS and srpm repodata will be > useful for yumdownloader, not yum itself. Yum does not and will not > have the ability to grab srpms. > > -- > Jesse Keating RHCE (geek.j2solutions.net) > Fedora Legacy Team (www.fedoralegacy.org) > GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2 (GNU/Linux) > > iD8DBQBD9PQ54v2HLvE71NURAmhDAJ4uIsZ2nh97H/gnpw90kp14IV13DgCePFc7 > XCwQYdhqauaHLcp22tUkhOw= > =46zl > -----END PGP SIGNATURE----- > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > will the .repo files for the debug packages be available in the fedora release package? I agree that it should be turned off by default but still it should be available, especially to simplify debugging with end users. regards, Rudolf Kastl From haydude at ezplanet.net Mon Feb 20 11:12:48 2006 From: haydude at ezplanet.net (Kaimano) Date: Mon, 20 Feb 2006 11:12:48 -0000 (GMT) Subject: The value of native java Message-ID: <48669.217.33.199.77.1140433968.squirrel@mauro.ezplanet.net> All, I was wondering around the value of embedding java within the operating system and some of the most important applications, beyond the academic exercise. I would rather focus on a better architectural design allowing for a more flexible package inter-dependency. The point of Java is "platform independency", if this requires more CPU and memory, that is OK, they come cheaper than the work necessary to maintain a parallel product line. If it is about license independence from Sun, Sun have never hinted that they will create any problem in future, it would all go to their disadvantage. Commercially, I would never recommend to rely on the native java packages. Just look at Eclipse, the masterpiece, 3.1.2 is out and FC5 dev is still on 3.1.1. What is FC4 on? I do not even know, never used, it did not even work with plugins like MyEclipseIDE. How much work has been spent to build those packages? It must have been man years. How much more will be needed to maintain them? I would rather spend my investment in time in re-designing the architecture of the system to take it to the next level. Please, see also my post on "The future of linux ..." From haydude at ezplanet.net Mon Feb 20 11:13:58 2006 From: haydude at ezplanet.net (Kaimano) Date: Mon, 20 Feb 2006 11:13:58 -0000 (GMT) Subject: The future of Linux - architecture and package inter-dependencies Message-ID: <49412.217.33.199.77.1140434038.squirrel@mauro.ezplanet.net> Hi All, Just joined this list, I started a topic on fedoraforum.org and I was suggested to refer my thoughts on this list as well. Sorry, is LONG. Here is a compendium of the messages I posted: ONE Linux represents a greatly stable platform and the FC team is doing a great work in improving the operating system, however I think that we should all take a step back and look at what the market and ourselves really need. What I am looking for, like, I believe 99% of the user base not involved with developing the OS, is: 1) to install an OS and forget about re-installs for at least two years 2) to be able to upgrade the applications I most use without having to re-install the operating system 3) to include among the applications I most use the following: * openoffice * evolution * http server * kde * gnome * firefox and mozilla * mysql and postgresql * eclipse * java to name a few. I am unsure about the real value of building java within the OS, so tightly that most packages builds depend on them. If I seriously need eclipse, I will go an get the latest JDK from Sun and the latest eclipse from eclipse.org and run them as such, they install in minutes and I can update them whenever available. FC5 has created a massive and unnecessary overhead of work essential to keep up with the latest releases. firefox 1.5 is hard to build for FC4 due to the dependencies, not to talk about evolution 2.4 openoffice and KDE just to name some. The dependencies on a miriad of packages make the effort ridicolously hard. The risk is to alienate potential users by forcing them to re-install their operating system whenever they/we want to use the latest release of an application that we really care about. My proposition is to start thinking of a Linux architecture that allows the re-build/re-placement of essential packages without having to rebuild most of the operating system, thus increasing the life-span and viability of a platform installation that need not to be replaced every year. TWO The problem is not updating from one version to the next, the problem is actually to keep up with updating the most important, though not system vital applications, without updating the core operating system. One guy using its own computer can do that accepting some difficulties and risk. Assume an hipotetical scenario of an organization that rolled out Linux desktop to 35000 workstations. The roadmap includes a desktop refresh in no less than five years due to costs implications. The core e-Mail application is evolution 2.0. A bug is found on evolution which requires upgrading to the latest 2.4. But ... evolution 2.4 requires python 2.4, our installed base is on a distribution based on python 2.3 (like FC2) which is deeply rooted in several applications. In addition, upgrading to python 2.4 involves upgrading also to a later version of db4, on which several other applications depend. Here we go, the chain is so long and tight that just a simple upgrade of evolution involves re-building most of the operating system, or ... rolling out a newer version. That puts me off recommending Linux Fedora or Red Hat for any business desktop platform. Are any of the core Fedora / Red Hat architects watching this forum? I would like to hear from them on this. THREE The good of this distro is right that there are discussions and participation from the community that can have its input, beside the fact that I am uncomfortable in participating, because I would be working for free for Red Hat that holds its fingers deep in the pie. As a matter of fact I am not particularly content with Fedora's license terms (the packages are open source, but we hold the rights on the OS structure, not just the logos, that belongs to us), an american lawyer must be behind those. To this end I believe that either we all work for free or we all get a share of the benefits. Having clarified this, I would like to make my little free contribution by drawing your attention to the fact that "having the latest version of a package at all costs" does not bring all the advantages that it could. On the contrary, I think that this tendency has brought Linux to being worse than Windows that we all criticized when got IE embedded. I would rather ensure that more attention is given to the system's architectural solution that should be based on modular components that, although interacting with each other, allow for the isolation of the applications into services that are as much as possible independent from each other, thus allowing for greater flexibility (in replacing them with newer or different versions), which in the end would bring to the system greater stability, lower cost of ownership (maintenance effort), and eventually deeper market penetration. If Fedora is what Red Hat will pick from, for their future releases, maybe Red Hat are missing the point, because their are getting spaghetti code. FOUR Quote: >Originally Posted by greenlead >Libraries and apps need to be written for backwards compatibility. An older app should still function if an updated library is installed. Precisely, this is at the foundation of any healthy information system, but it is not happeining with Linux right now, because of the lack of planning hidden behind the excuse that software solutions evolve rapidly. -- Mauro Mozzarelli eMail: mauro at ezplanet.net From arjan at fenrus.demon.nl Mon Feb 20 11:33:12 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Mon, 20 Feb 2006 12:33:12 +0100 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <49412.217.33.199.77.1140434038.squirrel@mauro.ezplanet.net> References: <49412.217.33.199.77.1140434038.squirrel@mauro.ezplanet.net> Message-ID: <1140435192.2979.45.camel@laptopd505.fenrus.org> On Mon, 2006-02-20 at 11:13 +0000, Kaimano wrote: > Hi All, > > Just joined this list, I started a topic on fedoraforum.org and I was > suggested to refer my thoughts on this list as well. Sorry, is LONG. > > Here is a compendium of the messages I posted: > > ONE > > Linux represents a greatly stable platform and the FC team is doing a > great work in improving the operating system, however I think that we > should all take a step back and look at what the market and ourselves > really need. > > What I am looking for, like, I believe 99% of the user base not involved > with developing the OS, is: > > 1) to install an OS and forget about re-installs for at least two years this FC already gives you ;) > 2) > to be able to upgrade the applications I most use without having to > re-install the operating system that's a hard one, see below \ > firefox 1.5 is hard to build for FC4 due to the dependencies, not to talk > about evolution 2.4 openoffice and KDE just to name some. The dependencies > on a miriad of packages make the effort ridicolously hard. > > The risk is to alienate potential users by forcing them to re-install > their operating system whenever they/we want to use the latest release of > an application that we really care about. > > My proposition is to start thinking of a Linux architecture that allows > the re-build/re-placement of essential packages without having to rebuild > most of the operating system, thus increasing the life-span and viability > of a platform installation that need not to be replaced every year. I think you are missing something here: these "essential packages" *ARE* most of the operating system. (If you divide FC into "OS" and "Applications", the essential packages you speak about fall under "OS", and are the DNA and fabric of what makes it an operating system). > > TWO > > The problem is not updating from one version to the next, the problem is > actually to keep up with updating the most important, though not system > vital applications, without updating the core operating system. One guy > using its own computer can do that accepting some difficulties and risk. again.. it's the same thing! "I want changes. But I also don't want changes" > The core e-Mail application is evolution 2.0. A bug is found on evolution > which requires upgrading to the latest 2.4. Why? You have a support contract with the vendor and you make them fix the bug in version 2.0. A bug should never ever be a reason to do an upgrade to half the OS. Missing features, sure, but bugs... no. From mailinglists at erwinrol.com Mon Feb 20 11:42:59 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Mon, 20 Feb 2006 12:42:59 +0100 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <1140435192.2979.45.camel@laptopd505.fenrus.org> References: <49412.217.33.199.77.1140434038.squirrel@mauro.ezplanet.net> <1140435192.2979.45.camel@laptopd505.fenrus.org> Message-ID: <1140435779.29378.6.camel@xpc.home.erwinrol.com> On Mon, 2006-02-20 at 12:33 +0100, Arjan van de Ven wrote: > On Mon, 2006-02-20 at 11:13 +0000, Kaimano wrote: > > The core e-Mail application is evolution 2.0. A bug is found on evolution > > which requires upgrading to the latest 2.4. > > Why? You have a support contract with the vendor and you make them fix > the bug in version 2.0. but, but, than you have pay money, and we just switched to Linux because everything is gratis ;-) - Erwin From tmus at tmus.dk Mon Feb 20 11:45:51 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 20 Feb 2006 12:45:51 +0100 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <1140435192.2979.45.camel@laptopd505.fenrus.org> References: <49412.217.33.199.77.1140434038.squirrel@mauro.ezplanet.net> <1140435192.2979.45.camel@laptopd505.fenrus.org> Message-ID: Arjan van de Ven wrote: >> 2) >> to be able to upgrade the applications I most use without having to >> re-install the operating system > > that's a hard one, see below > \ >> firefox 1.5 is hard to build for FC4 due to the dependencies, not to talk >> about evolution 2.4 openoffice and KDE just to name some. The dependencies >> on a miriad of packages make the effort ridicolously hard. >> If you want to use newer version of packages, there are normally no problems in doing so - The usual problem lies in the fact that the RAWHIDE packages are intended for newer core packages and components. You brought firefox 1.5 up, so let me use that as a simple example to illustrate my point. It's not possible to build the rawhide firefox packages on FC4, because they are MADE to REQUIRE cairo, which is not included in FC4. This does not mean that you cannot run firefox on FC4, though, you just need a) firefox packages that does not require cairo or b) cairo installed on your system. Check out nrpms.net - there are updated gnome/firefox/xx packages available for FC4 that you can upgrade most of your operating system without reinstalling. I'm currently running firefox 1.5.0.1 without cairo with great success on FC4. So what you need is a third party repository that give you the updated (not just security patched) versions of your core components... For most production (enterprise style) systems this is a bad idea, which is why i don't think we should ever expect this from a serious distro that should be usable in those places too. Hope this helps /Thomas From sundaram at fedoraproject.org Mon Feb 20 11:52:56 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 20 Feb 2006 17:22:56 +0530 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <1140435779.29378.6.camel@xpc.home.erwinrol.com> References: <49412.217.33.199.77.1140434038.squirrel@mauro.ezplanet.net> <1140435192.2979.45.camel@laptopd505.fenrus.org> <1140435779.29378.6.camel@xpc.home.erwinrol.com> Message-ID: <43F9AD98.6020800@fedoraproject.org> Erwin Rol wrote: >On Mon, 2006-02-20 at 12:33 +0100, Arjan van de Ven wrote: > > >>On Mon, 2006-02-20 at 11:13 +0000, Kaimano wrote: >> >> > > > >>>The core e-Mail application is evolution 2.0. A bug is found on evolution >>>which requires upgrading to the latest 2.4. >>> >>> >>Why? You have a support contract with the vendor and you make them fix >>the bug in version 2.0. >> >> > >but, but, than you have pay money, and we just switched to Linux because >everything is gratis ;-) > > > Could be gratis if the source is available under a appropriate license and you have the resources and time to do it yourself. On many occasions your expertise is not operating system development or more specifically not backporting Evolution bug fixes and it works out cheaper to pay a vendor. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From haydude at ezplanet.net Mon Feb 20 11:56:07 2006 From: haydude at ezplanet.net (Kaimano) Date: Mon, 20 Feb 2006 11:56:07 -0000 (GMT) Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <1140435779.29378.6.camel@xpc.home.erwinrol.com> References: <49412.217.33.199.77.1140434038.squirrel@mauro.ezplanet.net> <1140435192.2979.45.camel@laptopd505.fenrus.org> <1140435779.29378.6.camel@xpc.home.erwinrol.com> Message-ID: <19078.217.33.199.77.1140436567.squirrel@mauro.ezplanet.net> > On Mon, 2006-02-20 at 12:33 +0100, Arjan van de Ven wrote: >> On Mon, 2006-02-20 at 11:13 +0000, Kaimano wrote: > >> > The core e-Mail application is evolution 2.0. A bug is found on >> evolution >> > which requires upgrading to the latest 2.4. >> >> Why? You have a support contract with the vendor and you make them fix >> the bug in version 2.0. > > but, but, than you have pay money, and we just switched to Linux because > everything is gratis ;-) > I hope not. The point of Linux is freedom and independence, not being just "free". On the contrary, personally I spent more with Linux (if I value my time) than with any other OS I used. Anyway, I would like to focus more on the way we can improve it, starting from taking a step back and looking at the core architecture. The package inter-dependency at "RELEASE" level is killing it. Ideally I would start thinking of a real multi-tiered solution with a clear separation of concerns, and the establishment of core APIs which first priority should be to maintain the compatibility with previous releases. Too much is now changed from release to release only because of the lack of proper planning and design of the interfaces. -- Mauro M. From gnomeuser at gmail.com Mon Feb 20 12:02:17 2006 From: gnomeuser at gmail.com (David Nielsen) Date: Mon, 20 Feb 2006 13:02:17 +0100 Subject: The value of native java In-Reply-To: <48669.217.33.199.77.1140433968.squirrel@mauro.ezplanet.net> References: <48669.217.33.199.77.1140433968.squirrel@mauro.ezplanet.net> Message-ID: <1140436938.2163.4.camel@price.stavtrup-st.dk> man, 20 02 2006 kl. 11:12 +0000, skrev Kaimano: > All, > > I was wondering around the value of embedding java within the operating > system and some of the most important applications, beyond the academic > exercise. I would rather focus on a better architectural design allowing > for a more flexible package inter-dependency. > > The point of Java is "platform independency", if this requires more CPU > and memory, that is OK, they come cheaper than the work necessary to > maintain a parallel product line. If it is about license independence from > Sun, Sun have never hinted that they will create any problem in future, it > would all go to their disadvantage. Commercially, I would never recommend > to rely on the native java packages. Just look at Eclipse, the > masterpiece, 3.1.2 is out and FC5 dev is still on 3.1.1. What is FC4 on? I > do not even know, never used, it did not even work with plugins like > MyEclipseIDE. How much work has been spent to build those packages? It > must have been man years. How much more will be needed to maintain them? > > I would rather spend my investment in time in re-designing the > architecture of the system to take it to the next level. Please, see also > my post on "The future of linux ..." By the same right I could play devils advocate here and say that Mono gives you the exact same capabilities. - David *.NET advocate* Nielsen -- Obligatory shameless blog plug - the GNOME commentary located at: www.lovesunix.net/blog From pertusus at free.fr Mon Feb 20 12:15:49 2006 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 20 Feb 2006 13:15:49 +0100 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <19078.217.33.199.77.1140436567.squirrel@mauro.ezplanet.net> References: <49412.217.33.199.77.1140434038.squirrel@mauro.ezplanet.net> <1140435192.2979.45.camel@laptopd505.fenrus.org> <1140435779.29378.6.camel@xpc.home.erwinrol.com> <19078.217.33.199.77.1140436567.squirrel@mauro.ezplanet.net> Message-ID: <20060220121549.GC2995@free.fr> > The package inter-dependency at "RELEASE" level is killing it. > > Ideally I would start thinking of a real multi-tiered solution with a > clear separation of concerns, and the establishment of core APIs which > first priority should be to maintain the compatibility with previous > releases. > Too much is now changed from release to release only because of the lack > of proper planning and design of the interfaces. I think that this issue is not specific of fedora. The issue comes from upstream where incompatible api or abi are used. And it widely depends on which package you're looking at. For example glibc is very stable (thanks to proper use of library versionning), while recently (if I'm not wrong) gcc has been breaking binary compatibility quite a lot in g++. Other libraries may benefit from using library versionning (motif comes to my mind), but it isn't a fedora issue. Breaking api/abi isn't necessarily bad, as it allows to move on. Fedora doesn't avoid those changes as the aim of fedora is to use the newest technologies. If you want to use stable platforms, there are RHEL and its clones, or the debian stable, but then you won't be able to upgrade to newest application versions if the upstream doesn't allow it. To state it otherwise, if you want improvements in the stability of free software, then you'll have to help each of the project libraries that don't have a stable api/abi, but fedora uses what exists and is the most recent. -- Pat From sundaram at fedoraproject.org Mon Feb 20 12:22:07 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 20 Feb 2006 17:52:07 +0530 Subject: The value of native java In-Reply-To: <48669.217.33.199.77.1140433968.squirrel@mauro.ezplanet.net> References: <48669.217.33.199.77.1140433968.squirrel@mauro.ezplanet.net> Message-ID: <43F9B46F.8080000@fedoraproject.org> Kaimano wrote: >All, > >I was wondering around the value of embedding java within the operating >system and some of the most important applications, beyond the academic >exercise. I would rather focus on a better architectural design allowing >for a more flexible package inter-dependency. > > Java is not embedded within the operating system. Merely included as part of the distribution. You can very well choose to not install them or remove them post installation if its not required for you. >The point of Java is "platform independency", if this requires more CPU >and memory, that is OK, they come cheaper than the work necessary to >maintain a parallel product line. If it is about license independence from >Sun, Sun have never hinted that they will create any problem in future, it >would all go to their disadvantage. > Currently the Sun Java implementation is proprietary and Fedora does not include proprietary software. Refer to http://fedoraproject.org/wiki/ForbiddenItems >Commercially, I would never recommend >to rely on the native java packages. > The implementation within Fedora can use native packages but does not require them and can work fine with bytecode using GIJ. See http://fedoraproject.org/wiki/JavaFAQ. Multiple implementations like GCJ have actually helped in standardization by removing the use of internal non standard API usage within several Java programs. http://developer.classpath.org/mediation/ClasspathMigration -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From nicolas.mailhot at laposte.net Mon Feb 20 12:54:28 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 20 Feb 2006 13:54:28 +0100 (CET) Subject: The value of native java In-Reply-To: <48669.217.33.199.77.1140433968.squirrel@mauro.ezplanet.net> References: <48669.217.33.199.77.1140433968.squirrel@mauro.ezplanet.net> Message-ID: <3340.192.54.193.25.1140440068.squirrel@rousalka.dyndns.org> Hi, I won't quote your post because I disagree with pretty much all of it, and I don't expect you to understand my answers. You display a deep and basic misunderstanding of what Free Software in general and Fedora in particular are. Here is some food for thoughts : 1. item one : trusting "moral compacts" (or not). The free software movement was launched by people who felt betrayed by proprietary software vendors, which switched rules without warning because it suited them. They've learnt the hard way "moral compacts" are worth nothing when not backed by legal documents, if Sun wants people to commit on its tech it needs to commit itself first. 2. item 2 : as SCO n?e Caldera shows, using rationality to predict proprietary software companies policies is a deep mistake 3. item 3 : Sun in particular has an habit of performing 180? policy changes every few years (x86 Solaris anyone) you'd be mad to rely on them. Besides, Sun corporate culture is not Linux-friendly 4. item 4 : Free Software does not have a startup-like short-term horizon. GNU/Linux didn't get there in months, so what if some release sucks we'll get it right in the end. 5. item 5 : Red Hat Linux and later Fedora have always been more commited than most of the Linux market to Free Software. All people who (like you) thought it was a marketing mistake, and predicted Linux would bury Red Hat were proved wrong by the market. Go convince someone else, we'll bury them like the others. Eclipse already rules the Java IDE market (see Borland corporate plans) Proprietary J2EE vendors are feeling the heat of Tomcat, Geronimo and JBoss (see Oracle+JBoss, IBM+Gluecode, BEA moving up the foodchain with Aqualogic). The next step is the JVM and Fedora inclusion shows it won't be too long to come. At this point in time it would be madness for any closed software vendor to wed itself too tightly to Sun Java, let alone for a FOSS actor like Fedora. If you really think corporate might is sufficient to capture the IT market I invite you to reflect on Itanium fate. -- Nicolas Mailhot From mmkernel at ezplanet.net Mon Feb 20 12:55:29 2006 From: mmkernel at ezplanet.net (Mauro Mozzarelli) Date: Mon, 20 Feb 2006 12:55:29 -0000 (GMT) Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <20060220121549.GC2995@free.fr> References: <49412.217.33.199.77.1140434038.squirrel@mauro.ezplanet.net> <1140435192.2979.45.camel@laptopd505.fenrus.org> <1140435779.29378.6.camel@xpc.home.erwinrol.com> <19078.217.33.199.77.1140436567.squirrel@mauro.ezplanet.net> <20060220121549.GC2995@free.fr> Message-ID: <14317.217.33.199.77.1140440129.squirrel@mauro.ezplanet.net> > > I think that this issue is not specific of fedora. The issue comes from > upstream where incompatible api or abi are used. And it widely depends on > which package you're looking at. For example glibc is very stable (thanks No it is not, but this does not mean that Fedora could not or should not address it. Since this distribution is touching the cutting-edge Linux solutions, it could steer the community to focus more on architectural design which could bring more benefits than binning backwards compatibility to support the latest driver hack (just an example). -- Mauro Mozzarelli From sundaram at fedoraproject.org Mon Feb 20 13:09:37 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 20 Feb 2006 18:39:37 +0530 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <14317.217.33.199.77.1140440129.squirrel@mauro.ezplanet.net> References: <49412.217.33.199.77.1140434038.squirrel@mauro.ezplanet.net> <1140435192.2979.45.camel@laptopd505.fenrus.org> <1140435779.29378.6.camel@xpc.home.erwinrol.com> <19078.217.33.199.77.1140436567.squirrel@mauro.ezplanet.net> <20060220121549.GC2995@free.fr> <14317.217.33.199.77.1140440129.squirrel@mauro.ezplanet.net> Message-ID: <43F9BF91.2000801@fedoraproject.org> Mauro Mozzarelli wrote: >>I think that this issue is not specific of fedora. The issue comes from >>upstream where incompatible api or abi are used. And it widely depends on >>which package you're looking at. For example glibc is very stable (thanks >> >> > >No it is not, but this does not mean that Fedora could not or should not >address it. > Trying to shoehorn a ABI or API policy within Fedora would take a large amount of work without upstream involved in the decisions. >Since this distribution is touching the cutting-edge Linux >solutions, it could steer the community to focus more on architectural >design which could bring more benefits than binning backwards >compatibility to support the latest driver hack (just an example). > > Concentrate and help fix problems on the individual projects instead of drawing out grandiose plans. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From arjan at fenrus.demon.nl Mon Feb 20 13:15:37 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Mon, 20 Feb 2006 14:15:37 +0100 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <19078.217.33.199.77.1140436567.squirrel@mauro.ezplanet.net> References: <49412.217.33.199.77.1140434038.squirrel@mauro.ezplanet.net> <1140435192.2979.45.camel@laptopd505.fenrus.org> <1140435779.29378.6.camel@xpc.home.erwinrol.com> <19078.217.33.199.77.1140436567.squirrel@mauro.ezplanet.net> Message-ID: <1140441338.2979.58.camel@laptopd505.fenrus.org> > Ideally I would start thinking of a real multi-tiered solution with a > clear separation of concerns, and the establishment of core APIs which > first priority should be to maintain the compatibility with previous > releases. but now you're contradicting yourself a bit: First you want to use the most bleeding edge stuff, and now it's about running old stuff. You can argue perhaps "but if compat is 100% then I can always just drop in latest", but that's not realistic in the light of the "different bugs" argument. From mmkernel at ezplanet.net Mon Feb 20 13:21:17 2006 From: mmkernel at ezplanet.net (Mauro Mozzarelli) Date: Mon, 20 Feb 2006 13:21:17 -0000 (GMT) Subject: The value of native java In-Reply-To: <3340.192.54.193.25.1140440068.squirrel@rousalka.dyndns.org> References: <48669.217.33.199.77.1140433968.squirrel@mauro.ezplanet.net> <3340.192.54.193.25.1140440068.squirrel@rousalka.dyndns.org> Message-ID: <40475.217.33.199.77.1140441677.squirrel@mauro.ezplanet.net> > Hi, > > I won't quote your post because I disagree with pretty much all of it, and > I don't expect you to understand my answers. You display a deep and basic > misunderstanding of what Free Software in general and Fedora in particular > are. Here is some food for thoughts : > Nicolas, I do not consider "Free Software" as free or gratis, but as giving "freedom and openness". And although I disagree with you, I would not tell you that you misunderstand what "free software is" because you may be coming from a different background; nor I will attribute to you opinions that aren't yours (see 5). Besides, I accept your concerns on the future of an open java, although I am at the same time concerned about the multiplied effort in maintaining a parallel native packaged version of most of the open java libraries, tools and APIs. Why not just concentrate in delivering an alternative JDK/JRE, thus achieving real openness and independence from Sun and at the same time maintaining the separation of concerns? -- Mauro Mozzarelli eMail: mauro at ezplanet.net From sundaram at fedoraproject.org Mon Feb 20 13:25:55 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 20 Feb 2006 18:55:55 +0530 Subject: The value of native java In-Reply-To: <40475.217.33.199.77.1140441677.squirrel@mauro.ezplanet.net> References: <48669.217.33.199.77.1140433968.squirrel@mauro.ezplanet.net> <3340.192.54.193.25.1140440068.squirrel@rousalka.dyndns.org> <40475.217.33.199.77.1140441677.squirrel@mauro.ezplanet.net> Message-ID: <43F9C363.5020802@fedoraproject.org> Hi > >Besides, I accept your concerns on the future of an open java, although I >am at the same time concerned about the multiplied effort in maintaining a >parallel native packaged version of most of the open java libraries, tools >and APIs. Why not just concentrate in delivering an alternative JDK/JRE, >thus achieving real openness and independence from Sun and at the same >time maintaining the separation of concerns? > > Again, the implementation in Fedora does not require native packages. Kindly read up on the implementation. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From mharris at mharris.ca Mon Feb 20 13:32:38 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 20 Feb 2006 08:32:38 -0500 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <19078.217.33.199.77.1140436567.squirrel@mauro.ezplanet.net> References: <49412.217.33.199.77.1140434038.squirrel@mauro.ezplanet.net> <1140435192.2979.45.camel@laptopd505.fenrus.org> <1140435779.29378.6.camel@xpc.home.erwinrol.com> <19078.217.33.199.77.1140436567.squirrel@mauro.ezplanet.net> Message-ID: <43F9C4F6.5030700@mharris.ca> Kaimano wrote: > I hope not. The point of Linux is freedom and independence, not being just > "free". On the contrary, personally I spent more with Linux (if I value my > time) than with any other OS I used. > > Anyway, I would like to focus more on the way we can improve it, starting > from taking a step back and looking at the core architecture. > > The package inter-dependency at "RELEASE" level is killing it. That's kindof funny. ;o) If this is something "killing it" as you say, then why are the number of people using Linux greater right now than at any previous time? Why are more and more people/companies utilizing Linux for more and more jobs/tasks every day? Why are many people/companies completely migrating away from other operating systems such as proprietary UNICES, Windows, and other platforms to Linux now more than ever before? What specific signs do you have, which unconditionally show the problem you have put forth, to be directly responsible for "killing it" so to speak? I see no signs of people stopping using Fedora Core or any other Linux distribution which backs up such a claim. In reality, more and more people/companies/etc. are using Linux every day, and that is more likely to increase if anything than to ever decrease. I see no "killing it" happening, unless by "it" you mean something other than Fedora Core or Linux in general, as neither are dying by a long shot. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From overholt at redhat.com Mon Feb 20 13:37:40 2006 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 20 Feb 2006 08:37:40 -0500 Subject: The value of native java In-Reply-To: <48669.217.33.199.77.1140433968.squirrel@mauro.ezplanet.net> References: <48669.217.33.199.77.1140433968.squirrel@mauro.ezplanet.net> Message-ID: <20060220133740.GA19155@redhat.com> * Kaimano [2006-02-20 06:13]: > > Just look at Eclipse, the masterpiece, 3.1.2 is out and FC5 dev is still > on 3.1.1. What is FC4 on? 3.1.2 is in rawhide and I'm going to push out an update to FC4 when I get a chance. Andrew From sct at redhat.com Mon Feb 20 13:41:02 2006 From: sct at redhat.com (Stephen C. Tweedie) Date: Mon, 20 Feb 2006 08:41:02 -0500 Subject: Xen issues - Was Xen network performance problem during kickstart. In-Reply-To: <1140157902.3229.32.camel@dragon.sys.intra> References: <1139987549.21111.68.camel@dragon.sys.intra> <1140052865.2302.64.camel@host-81-191-138-132.bluecom.no> <1140060379.21111.145.camel@dragon.sys.intra> <1140078535.4651.84.camel@dragon.sys.intra> <1140157902.3229.32.camel@dragon.sys.intra> Message-ID: <1140442863.3357.4.camel@orbit.scot.redhat.com> Hi, On Fri, 2006-02-17 at 15:31 +0900, Naoki wrote: > ------------[ cut here ]------------ > kernel BUG at include/asm/xor.h:633! > invalid opcode: 0000 [#1] That was supposed to be fixed (bug 177644); I'll chase this up and see what's happening here. > 2) Ridiculously slow : 4 hours for a guest install of ~500mb. No > identifiable host problem. I'm trying to do a network install and the > instance running right now is doing less than 1 byte/sec according to > "xm top". Works fine for me. This could be any number of things, from not giving the domU enough memory to interrupt problems. We'd need more info to debug. > 3) Install crashes out at random points into install : > > > Traceback (most recent call last): File > > > "/usr/bin/anaconda", line 1210, in ? > > > > > > handleException(dispatch, intf, sys.exc_info()) ... > > > return _snack.reflow(text, width, flexDown, flexUp) > > > > > > TypeError: argument 1 must be string without null bytes, not str > > > install exited > > > abnormally Looks like an anaconda bug; could you file a bug report, please? Thanks, Stephen From mmkernel at ezplanet.net Mon Feb 20 13:47:02 2006 From: mmkernel at ezplanet.net (Mauro Mozzarelli) Date: Mon, 20 Feb 2006 13:47:02 -0000 (GMT) Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <43F9C4F6.5030700@mharris.ca> References: <49412.217.33.199.77.1140434038.squirrel@mauro.ezplanet.net> <1140435192.2979.45.camel@laptopd505.fenrus.org> <1140435779.29378.6.camel@xpc.home.erwinrol.com> <19078.217.33.199.77.1140436567.squirrel@mauro.ezplanet.net> <43F9C4F6.5030700@mharris.ca> Message-ID: <65095.217.33.199.77.1140443222.squirrel@mauro.ezplanet.net> > Kaimano wrote: >> >> The package inter-dependency at "RELEASE" level is killing it. > > That's kindof funny. ;o) If this is something "killing it" as you > say, then why are the number of people using Linux greater right now > than at any previous time? Why are more and more people/companies I think that this phrase might have been mis-interpreted, "killing it" here is meant as making it overly complicated; a fudge without plan, that is hard to maintain. Of course the end users do not see that, but we are not in an end-user mailing list. The concerns are about spending more time for planning and design in order to move towards a really open platform, otherwise the risk is to end up with an open source so complicated to maintain that it would not make any difference if it was proprietary and secret. -- Mauro From sundaram at fedoraproject.org Mon Feb 20 13:49:57 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 20 Feb 2006 19:19:57 +0530 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <65095.217.33.199.77.1140443222.squirrel@mauro.ezplanet.net> References: <49412.217.33.199.77.1140434038.squirrel@mauro.ezplanet.net> <1140435192.2979.45.camel@laptopd505.fenrus.org> <1140435779.29378.6.camel@xpc.home.erwinrol.com> <19078.217.33.199.77.1140436567.squirrel@mauro.ezplanet.net> <43F9C4F6.5030700@mharris.ca> <65095.217.33.199.77.1140443222.squirrel@mauro.ezplanet.net> Message-ID: <43F9C905.60402@fedoraproject.org> Mauro Mozzarelli wrote: >>Kaimano wrote: >> >> >>>The package inter-dependency at "RELEASE" level is killing it. >>> >>> >>That's kindof funny. ;o) If this is something "killing it" as you >>say, then why are the number of people using Linux greater right now >>than at any previous time? Why are more and more people/companies >> >> > >I think that this phrase might have been mis-interpreted, "killing it" >here is meant as making it overly complicated; a fudge without plan, that >is hard to maintain. Of course the end users do not see that, but we are >not in an end-user mailing list. > > Killing it is a unnecessary dramatic phrase prone to various interpretations. >The concerns are about spending more time for planning and design in order >to move towards a really open platform, otherwise the risk is to end up >with an open source so complicated to maintain that it would not make any >difference if it was proprietary and secret. > > How are you willing to help? -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From mmkernel at ezplanet.net Mon Feb 20 14:01:43 2006 From: mmkernel at ezplanet.net (Mauro Mozzarelli) Date: Mon, 20 Feb 2006 14:01:43 -0000 (GMT) Subject: The future of Linux - architecture and package inter-dependencies Message-ID: <16330.217.33.199.77.1140444103.squirrel@mauro.ezplanet.net> Rahul, > Killing it is a unnecessary dramatic phrase prone to various > interpretations. > Please forgive my english that is not my first language and I started learning it serioulsy only in my late 30s. > How are you willing to help? Good question, I thought that this discussion was a start. This is a task that requires influencing, management and enterprise architecture skills other than time. It must be a team work to succeed. Is there a team that I could join? Would a team have to be formed? -- Mauro -- Mauro Mozzarelli eMail: mauro at ezplanet.net From sundaram at fedoraproject.org Mon Feb 20 14:05:57 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 20 Feb 2006 19:35:57 +0530 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <16330.217.33.199.77.1140444103.squirrel@mauro.ezplanet.net> References: <16330.217.33.199.77.1140444103.squirrel@mauro.ezplanet.net> Message-ID: <43F9CCC5.5000807@fedoraproject.org> Hi > > >>How are you willing to help? >> >> > >Good question, I thought that this discussion was a start. >This is a task that requires influencing, management and enterprise >architecture skills other than time. It must be a team work to succeed. Is >there a team that I could join? Would a team have to be formed? > > I hear a lot of buzzwords. If it requires forming a whole new team you need to identify specific set of issues and a action plan in which you can define your own work without getting a lot of other people involved and then start working on that. If its a good plan and it shows up as such on your work, I am sure others can get involved. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From seanlkml at sympatico.ca Mon Feb 20 13:16:32 2006 From: seanlkml at sympatico.ca (sean) Date: Mon, 20 Feb 2006 08:16:32 -0500 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <19078.217.33.199.77.1140436567.squirrel@mauro.ezplanet.net> References: <49412.217.33.199.77.1140434038.squirrel@mauro.ezplanet.net> <1140435192.2979.45.camel@laptopd505.fenrus.org> <1140435779.29378.6.camel@xpc.home.erwinrol.com> <19078.217.33.199.77.1140436567.squirrel@mauro.ezplanet.net> Message-ID: On Mon, 20 Feb 2006 11:56:07 -0000 (GMT) "Kaimano" wrote: > I hope not. The point of Linux is freedom and independence, not being just > "free". On the contrary, personally I spent more with Linux (if I value my > time) than with any other OS I used. To be realistic, Linux is still essentially in early public beta mode (at best) in regard to the desktop. Eventually the churn will slow down, but not until a fair bit more development is done. Expectations of Linux desktop users need to be set appropriately. Hand wringing about the current state of affairs ignores the fact that massive amounts of energy are being poured into making it better. > Anyway, I would like to focus more on the way we can improve it, starting > from taking a step back and looking at the core architecture. > > The package inter-dependency at "RELEASE" level is killing it. There is no evidence that Linux is dying. > Ideally I would start thinking of a real multi-tiered solution with a > clear separation of concerns, and the establishment of core APIs which > first priority should be to maintain the compatibility with previous > releases. > Too much is now changed from release to release only because of the lack > of proper planning and design of the interfaces. There is no practical way to demand, force, cajole, or beg everyone who contributes to the evolution of Linux to conform to some grand roadmap or to always maintain backward compatibility. Even if there were, it would just create a different set of tradeoffs from the ones we have today. Linux isn't a panacea, it's just the best choice you have if you value freedom. For your needs today you might want to consider using long-lived distributions such as RHEL that guarantee compatability for five or more years so that you can be sure you don't need to reinstall. But there are other tradeoffs you must make if you go down that road. Sean From riel at redhat.com Mon Feb 20 14:11:29 2006 From: riel at redhat.com (Rik van Riel) Date: Mon, 20 Feb 2006 09:11:29 -0500 (EST) Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <16330.217.33.199.77.1140444103.squirrel@mauro.ezplanet.net> References: <16330.217.33.199.77.1140444103.squirrel@mauro.ezplanet.net> Message-ID: On Mon, 20 Feb 2006, Mauro Mozzarelli wrote: > > How are you willing to help? > > Good question, I thought that this discussion was a start. This is a > task that requires influencing, management and enterprise architecture > skills other than time. It must be a team work to succeed. Is there a > team that I could join? Would a team have to be formed? I think the first step would be to describe the problem in more concrete terms. Actual problems that could be addressed, instead of vague generalizations that could apply to anything. Having concrete goals would be good, too. If the goals and the problem description are interesting and deemed realistic, then I'm sure developers would join your effort. -- All Rights Reversed From felipe.alfaro at gmail.com Mon Feb 20 14:22:50 2006 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Mon, 20 Feb 2006 15:22:50 +0100 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <1140435779.29378.6.camel@xpc.home.erwinrol.com> References: <49412.217.33.199.77.1140434038.squirrel@mauro.ezplanet.net> <1140435192.2979.45.camel@laptopd505.fenrus.org> <1140435779.29378.6.camel@xpc.home.erwinrol.com> Message-ID: <6f6293f10602200622v4c5d2179u1abd4f62dcce4f80@mail.gmail.com> > but, but, than you have pay money, and we just switched to Linux > because everything is gratis ;-) I switched to Linux because of the freedom it gives to me, not only because it is gratis. You can also have a "gratis" version of any pirated software. From nicolas.mailhot at laposte.net Mon Feb 20 14:32:14 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 20 Feb 2006 15:32:14 +0100 (CET) Subject: The value of native java In-Reply-To: <40475.217.33.199.77.1140441677.squirrel@mauro.ezplanet.net> References: <48669.217.33.199.77.1140433968.squirrel@mauro.ezplanet.net> <3340.192.54.193.25.1140440068.squirrel@rousalka.dyndns.org> <40475.217.33.199.77.1140441677.squirrel@mauro.ezplanet.net> Message-ID: <56676.192.54.193.25.1140445934.squirrel@rousalka.dyndns.org> Le Lun 20 f?vrier 2006 14:21, Mauro Mozzarelli a ?crit : > Nicolas, > > I do not consider "Free Software" as free or gratis, but as giving > "freedom and openness". And although I disagree with you, I would not tell > you that you misunderstand what "free software is" because you may be > coming from a different background; Mauro, I intentionnaly used the term "Free Software" and not "Open Source" or even "FOSS". The backbone of the Free Software model are the licensing rules. The GPL - not actual software code - is the single most important reason for the FSF influence in the Free Software world (feel free to read the kernel archives to see if core developpers consider their licensing model incidental). XFree86 broke up over licensing (and the GPL in particular) BSD/Linux mostly disagree over licensing (and the GPL in particular) Mozilla had to relicense a boatload of code to accomodate licensing problems (and the GPL) Sun may have to relicence OpenSolaris (to the GPL v3) If you actually think the Java licensing model can be dismissed by "If it is about license independence from Sun, Sun have never hinted that they will create any problem in future, it would all go to their disadvantage", I'm sorry, but you display a deep and basic misunderstanding of what Free Software in general and Fedora in particular are. Fedora has always been about hard FOSS compliance, not "somehow open and free" software. FOSS does not rely on benevolent vendor dictatorship, but on actual code and licenses. Regards, -- Nicolas Mailhot From arjan at fenrus.demon.nl Mon Feb 20 14:35:02 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Mon, 20 Feb 2006 15:35:02 +0100 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <6f6293f10602200622v4c5d2179u1abd4f62dcce4f80@mail.gmail.com> References: <49412.217.33.199.77.1140434038.squirrel@mauro.ezplanet.net> <1140435192.2979.45.camel@laptopd505.fenrus.org> <1140435779.29378.6.camel@xpc.home.erwinrol.com> <6f6293f10602200622v4c5d2179u1abd4f62dcce4f80@mail.gmail.com> Message-ID: <1140446102.2979.61.camel@laptopd505.fenrus.org> On Mon, 2006-02-20 at 15:22 +0100, Felipe Alfaro Solana wrote: > > but, but, than you have pay money, and we just switched to Linux > > because everything is gratis ;-) > > I switched to Linux because of the freedom it gives to me, not only > because it is gratis. You can also have a "gratis" version of any > pirated software. sigh... so this goes waaay off to an irrelevant tangent. My point was that having a bug isn't a valid reason to upgrade to a major new version (and all the dependency hell that that generates). The more right solution is to fix the bug if it's important enough. From pertusus at free.fr Mon Feb 20 14:56:32 2006 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 20 Feb 2006 15:56:32 +0100 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <16330.217.33.199.77.1140444103.squirrel@mauro.ezplanet.net> References: <16330.217.33.199.77.1140444103.squirrel@mauro.ezplanet.net> Message-ID: <20060220145632.GD2861@free.fr> > > How are you willing to help? > > Good question, I thought that this discussion was a start. > This is a task that requires influencing, management and enterprise > architecture skills other than time. It must be a team work to succeed. Is > there a team that I could join? Would a team have to be formed? As allready said, what needs to be influenced are the individual projects. There is nothing like a team that tries to help keep api and abi stable for all the projects and it is dubious that forming one would make sense. If you find that some library has a stable binary interface that is kept across versions and is used by most applications, and is mixed with a changing interface, then you could help by providing library version scripts to these libraries. This could potentially solve the api/abi change issue. As I said allready this would, for example benefit to openmotf/lesstif, because most apps compiled against openmotif use a stable subset of the api/abi. But openmotif isn't even free software, so... Here are sources of information, with the relevant part of the ld manual: http://www.gnu.org/software/binutils/manual/ld-2.9.1/html_node/ld_25.html#SEC25 A generic resource I found on that subject: http://www.usenix.org/publications/library/proceedings/als00/2000papers/papers/full_papers/browndavid/browndavid_html/ There are many other sources of incompatibility than abi/api changes, but abi/apip changes seemed to be on your list. -- Pat From alan at redhat.com Mon Feb 20 15:01:58 2006 From: alan at redhat.com (Alan Cox) Date: Mon, 20 Feb 2006 10:01:58 -0500 Subject: The value of native java In-Reply-To: <56676.192.54.193.25.1140445934.squirrel@rousalka.dyndns.org> References: <48669.217.33.199.77.1140433968.squirrel@mauro.ezplanet.net> <3340.192.54.193.25.1140440068.squirrel@rousalka.dyndns.org> <40475.217.33.199.77.1140441677.squirrel@mauro.ezplanet.net> <56676.192.54.193.25.1140445934.squirrel@rousalka.dyndns.org> Message-ID: <20060220150158.GA27247@devserv.devel.redhat.com> On Mon, Feb 20, 2006 at 03:32:14PM +0100, Nicolas Mailhot wrote: > XFree86 broke up over licensing (and the GPL in particular) Not very true. Its a bit like saying the first world war started because of an assassination. That was merely the last straw. > Sun may have to relicence OpenSolaris (to the GPL v3) "Have to" ?? Alan -- "Have you noticed the way people's intelligence capabilities decline sharply the minute they start waving guns around?" -- Dr. Who From mmkernel at ezplanet.net Mon Feb 20 15:05:17 2006 From: mmkernel at ezplanet.net (Mauro Mozzarelli) Date: Mon, 20 Feb 2006 15:05:17 -0000 (GMT) Subject: The value of native java In-Reply-To: <56676.192.54.193.25.1140445934.squirrel@rousalka.dyndns.org> References: <48669.217.33.199.77.1140433968.squirrel@mauro.ezplanet.net> <3340.192.54.193.25.1140440068.squirrel@rousalka.dyndns.org> <40475.217.33.199.77.1140441677.squirrel@mauro.ezplanet.net> <56676.192.54.193.25.1140445934.squirrel@rousalka.dyndns.org> Message-ID: <1585.217.33.199.77.1140447917.squirrel@mauro.ezplanet.net> Nicolas, > The GPL - not actual software code - is the single most important > reason for the FSF influence in the Free Software world (feel free to read > the kernel archives to see if core developpers consider their licensing > model incidental). Clearly we come from different cultural backgrounds. The licensing rules are all an american thing that from my point of view can be perceived as childish arguments. I grew up in a culture where helping your classmates and colleagues was honorable. On the other side of the ocean instead I understand that people are more competitive and protective and would cover their work with their hand to avoid their classmate to copy it. I do not expect you to understand this. Europeans have invented several things, americans have invented the patents. Look at the example of the telephone (invented by A. Meucci, patented by G. Bell several years later). But I consider myself to be lucky to be living in Europe where software patents are not allowed because they could undermine real freedom and progress. The various american versions of licenses do not influence my attitude towards open source or free software. As long as it is there and it can be used, I will use it, and if I can make any contribution, I will, regardless. Perhaps this attitude does not make Europeans materially reach, but it makes me feel "free" and culturally reach anyway. -- Mauro From icon at fedoraproject.org Mon Feb 20 15:17:41 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Mon, 20 Feb 2006 10:17:41 -0500 Subject: The value of native java In-Reply-To: <1585.217.33.199.77.1140447917.squirrel@mauro.ezplanet.net> References: <48669.217.33.199.77.1140433968.squirrel@mauro.ezplanet.net> <3340.192.54.193.25.1140440068.squirrel@rousalka.dyndns.org> <40475.217.33.199.77.1140441677.squirrel@mauro.ezplanet.net> <56676.192.54.193.25.1140445934.squirrel@rousalka.dyndns.org> <1585.217.33.199.77.1140447917.squirrel@mauro.ezplanet.net> Message-ID: <43F9DD95.4050902@fedoraproject.org> Mauro Mozzarelli wrote: > Perhaps this attitude does not make Europeans materially reach, but it > makes me feel "free" and culturally reach anyway. Yes, thank you for that lovely troll. The world involves ALL of the world, not just Western Europe. There are places that are less free. There are places that are a lot more free. We are here to forge a global project, and the aim of this project is to be available to as many people as possible, without any potential legal problems for them. If this means that we have to pussy-foot around the issue of patents in order to be able to make our product available to the widest possible audience, then we will do so. Trolling about this won't make the issue go away. PS: I believe someone over there just resigned from a government post because he wore a shirt with a cartoon on it. There, now we're even and can go back to being productive instead of mockingly pointing fingers across the ocean. It really makes all of us look like a bunch of rear-end cavities. -- Konstantin Ryabitsev McGill University WSG Jayne: "I'll be in my bunk." --Episode #10, "War Stories" From rhally at mindspring.com Mon Feb 20 15:21:07 2006 From: rhally at mindspring.com (Richard Hally) Date: Mon, 20 Feb 2006 10:21:07 -0500 Subject: torrent page? Message-ID: <43F9DE63.5030803@mindspring.com> Anyone have an idea when this page will be updated for test3? http://torrent.fedoraproject.org/ From rc040203 at freenet.de Mon Feb 20 15:22:00 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 20 Feb 2006 16:22:00 +0100 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <20060220145632.GD2861@free.fr> References: <16330.217.33.199.77.1140444103.squirrel@mauro.ezplanet.net> <20060220145632.GD2861@free.fr> Message-ID: <1140448921.21764.589.camel@mccallum.corsepiu.local> On Mon, 2006-02-20 at 15:56 +0100, Patrice Dumas wrote: > But openmotif isn't even free software, Depends on your definition of "free software". Motif had been closed source until several years ago, but times are a-changing: # rpm -q --qf '%{LICENSE}\n' openmotif Open Group Public License And lesstif, meanwhile is more or less without any practical importance, anymore (It's not even part of FC or FE anymore) Ralf From sundaram at fedoraproject.org Mon Feb 20 15:26:40 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 20 Feb 2006 20:56:40 +0530 Subject: torrent page? In-Reply-To: <43F9DE63.5030803@mindspring.com> References: <43F9DE63.5030803@mindspring.com> Message-ID: <43F9DFB0.7040901@fedoraproject.org> Richard Hally wrote: > Anyone have an idea when this page will be updated for test3? > > http://torrent.fedoraproject.org/ > Try refreshing the page ;-) -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From rhally at mindspring.com Mon Feb 20 15:28:29 2006 From: rhally at mindspring.com (Richard Hally) Date: Mon, 20 Feb 2006 10:28:29 -0500 Subject: torrent page? In-Reply-To: <43F9DE63.5030803@mindspring.com> References: <43F9DE63.5030803@mindspring.com> Message-ID: <43F9E01D.7030009@mindspring.com> Richard Hally wrote: > Anyone have an idea when this page will be updated for test3? > > http://torrent.fedoraproject.org/ > perfect timing! it is updated now. thanks From alan at redhat.com Mon Feb 20 15:35:33 2006 From: alan at redhat.com (Alan Cox) Date: Mon, 20 Feb 2006 10:35:33 -0500 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <1140448921.21764.589.camel@mccallum.corsepiu.local> References: <16330.217.33.199.77.1140444103.squirrel@mauro.ezplanet.net> <20060220145632.GD2861@free.fr> <1140448921.21764.589.camel@mccallum.corsepiu.local> Message-ID: <20060220153533.GB29559@devserv.devel.redhat.com> On Mon, Feb 20, 2006 at 04:22:00PM +0100, Ralf Corsepius wrote: > On Mon, 2006-02-20 at 15:56 +0100, Patrice Dumas wrote: > > But openmotif isn't even free software, > > Depends on your definition of "free software". Motif had been closed > source until several years ago, but times are a-changing: OpenMotif is not free software by the FSF test. You can't for example use it with proprietary Nvidia drivers loaded. From che666 at gmail.com Mon Feb 20 15:49:53 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Mon, 20 Feb 2006 16:49:53 +0100 Subject: The value of native java In-Reply-To: <3340.192.54.193.25.1140440068.squirrel@rousalka.dyndns.org> References: <48669.217.33.199.77.1140433968.squirrel@mauro.ezplanet.net> <3340.192.54.193.25.1140440068.squirrel@rousalka.dyndns.org> Message-ID: 2006/2/20, Nicolas Mailhot : > Hi, > > I won't quote your post because I disagree with pretty much all of it, and > I don't expect you to understand my answers. You display a deep and basic > misunderstanding of what Free Software in general and Fedora in particular > are. Here is some food for thoughts : > > 1. item one : trusting "moral compacts" (or not). The free software > movement was launched by people who felt betrayed by proprietary software > vendors, which switched rules without warning because it suited them. > They've learnt the hard way "moral compacts" are worth nothing when not > backed by legal documents, if Sun wants people to commit on its tech it > needs to commit itself first. Sun at this point is not open source unfriendly. One could even argue that you can download the sun java source. Its still not includeable in the fedora distro. and well.. if it cant go in... its not really relevant to us real fedorians ;) > > 2. item 2 : as SCO n?e Caldera shows, using rationality to predict > proprietary software companies policies is a deep mistake > > 3. item 3 : Sun in particular has an habit of performing 180? policy > changes every few years (x86 Solaris anyone) you'd be mad to rely on them. > Besides, Sun corporate culture is not Linux-friendly Sun at the moment though is rather open source friendly. > > 4. item 4 : Free Software does not have a startup-like short-term horizon. > GNU/Linux didn't get there in months, so what if some release sucks we'll > get it right in the end. agreed. who cares about another iteration. we get the better product in the end ;) > > 5. item 5 : Red Hat Linux and later Fedora have always been more commited > than most of the Linux market to Free Software. All people who (like you) > thought it was a marketing mistake, and predicted distro which made compromises with closed vendors like Sun> Linux would > bury Red Hat were proved wrong by the market. Go convince someone else, > we'll bury them like the others. Guess why i picked redhat in the past? As someone that required closed source stuff when i started i sometimes felt like a "victim" of the zealots. But with more understanding of what its all about i got it finally and became a zealot myself. No one can ever really fix the hacked windows winmodem driver i required back then e.g. .... if youd hack around proprietary crap instead of creating real solutions you will never come there... it would always stay some "hacky but working solution to make whiners shut up". Workarounds usually just discourage people from putting effort into real solutions unless the workarounds are ugly enough perhaps. > > Eclipse already rules the Java IDE market (see Borland corporate plans) > Proprietary J2EE vendors are feeling the heat of Tomcat, Geronimo and > JBoss (see Oracle+JBoss, IBM+Gluecode, BEA moving up the foodchain with > Aqualogic). > The next step is the JVM and Fedora inclusion shows it won't be too long > to come. > > At this point in time it would be madness for any closed software vendor > to wed itself too tightly to Sun Java, let alone for a FOSS actor like > Fedora. If you really think corporate might is sufficient to capture the > IT market I invite you to reflect on Itanium fate. > > -- > Nicolas Mailhot > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > another opinion, Rudolf Kastl From che666 at gmail.com Mon Feb 20 15:53:34 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Mon, 20 Feb 2006 16:53:34 +0100 Subject: Open Xchange for FC5 with GCJ 4.1 In-Reply-To: <1140392039.17385.390.camel@xpc.home.erwinrol.com> References: <1140392039.17385.390.camel@xpc.home.erwinrol.com> Message-ID: 2006/2/20, Erwin Rol : > Hey all, > > I uploaded two SRPM files for FC5 (Fedora Core 5 AKA Rawhide). Before > you even download those files take note of the following; > > 1) Do _NOT_ bother the Open Xchange developers with bugs/errors/problems > found in those SRPM's, contact me instead. > > 2) Do _NOT_ file bug reports in OX bugzilla for bugs you find in those > SRPM's, contact me instead. > > 3) Do _NOT_ use those SRPM's on a production system, they might destroy, > your postgresql, openldap, tomcat and httpd setup. > > 4) It is highly unlikely that those SRPM's work on anything else but FC5 > with GCJ 4.1. > > Now to what i have done, first of all I needed a CVS version of gnu > javamail. That version can be found here; > http://www.erwinrol.com/downloads/software/ox_javamail-1.3.0-1.CVS20060218.src.rpm > As you can see the name is different from the default name, this is to > make it possible to keep your original javamail jar files, so other > programs do not break. > > Build and install this RPM first. > > Than you can download the Open Xchange RPM; > http://www.erwinrol.com/downloads/software/open-xchange-0.8.2-RC3.ER.20060219234052.src.rpm > Building that RPM should work, but it might be missing a bunch of > Dependencies and so you might run into trouble, if that happens please > report the missing dependencies to me. Before building the SRPM change > the passwords in the spec file. > > the files to setup LDAP and Postgres might not work, it would be best to > test it against a known good LDAP and postgres setup, that way you don't > hunt bugs that are just setup errors. > > The RPM holds a 500k patch, so you can see it changes a lot, and surely > breaks things too. The way i worked was, simply move from exception to > exception. Play around a bit with it, and than look in the log files for > exceptions, and than fix those. That is a lot of work but it isn't even > that complicated, although the OX source code is not very well > documented and so understanding what it should do is not always easy. > > Of course not everything works, but database access seems to work now > with postgresql 8.1 (both server and jdbc). Webmail also seems to be > able to read mail. And I can login, so Ldap also kind of works. I think > ldap addressbook is still a problem, but that is because the ldap part > is a serious hack, the imap stuff also has some hanks. > > Since I have a busy week coming up I will continue with the development > next weekend, I hope some ppl could play around with it in the meanwhile > and report all problems to me, so I can fix them next weekend. > > - Erwin > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > absolutely awesome! i cant wait to give the stuff a test spin on rawhide. regards, Rudolf Kastl p.s. keep up the good work! ;)) From nicolas.mailhot at laposte.net Mon Feb 20 15:59:41 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 20 Feb 2006 16:59:41 +0100 (CET) Subject: The value of native java In-Reply-To: <20060220150158.GA27247@devserv.devel.redhat.com> References: <48669.217.33.199.77.1140433968.squirrel@mauro.ezplanet.net> <3340.192.54.193.25.1140440068.squirrel@rousalka.dyndns.org> <40475.217.33.199.77.1140441677.squirrel@mauro.ezplanet.net> <56676.192.54.193.25.1140445934.squirrel@rousalka.dyndns.org> <20060220150158.GA27247@devserv.devel.redhat.com> Message-ID: <19521.192.54.193.25.1140451181.squirrel@rousalka.dyndns.org> Le Lun 20 f?vrier 2006 16:01, Alan Cox a ?crit : > On Mon, Feb 20, 2006 at 03:32:14PM +0100, Nicolas Mailhot wrote: >> XFree86 broke up over licensing (and the GPL in particular) > > Not very true. Its a bit like saying the first world war started because > of an assassination. That was merely the last straw. That is could be the last straw at all shows we care much more about licensing than other software entities. >> Sun may have to relicence OpenSolaris (to the GPL v3) > > "Have to" ?? May. And the only reason they even consider it is because of all the annoying people who worry about the actual license. Regards, -- Nicolas Mailhot From rc040203 at freenet.de Mon Feb 20 16:10:43 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 20 Feb 2006 17:10:43 +0100 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <20060220153533.GB29559@devserv.devel.redhat.com> References: <16330.217.33.199.77.1140444103.squirrel@mauro.ezplanet.net> <20060220145632.GD2861@free.fr> <1140448921.21764.589.camel@mccallum.corsepiu.local> <20060220153533.GB29559@devserv.devel.redhat.com> Message-ID: <1140451843.21764.593.camel@mccallum.corsepiu.local> On Mon, 2006-02-20 at 10:35 -0500, Alan Cox wrote: > On Mon, Feb 20, 2006 at 04:22:00PM +0100, Ralf Corsepius wrote: > > On Mon, 2006-02-20 at 15:56 +0100, Patrice Dumas wrote: > > > But openmotif isn't even free software, > > > > Depends on your definition of "free software". Motif had been closed > > source until several years ago, but times are a-changing: > > OpenMotif is not free software by the FSF test. You can't for example use it > with proprietary Nvidia drivers loaded. Only if you consider Nvidia's drivers to be integral part of the kernel. I consider them to be optional add-ons/plug-ins. Ralf From naoki at valuecommerce.com Mon Feb 20 16:11:04 2006 From: naoki at valuecommerce.com (Naoki) Date: Tue, 21 Feb 2006 01:11:04 +0900 Subject: Xen issues - Was Xen network performance problem during kickstart. In-Reply-To: <1140442863.3357.4.camel@orbit.scot.redhat.com> References: <1139987549.21111.68.camel@dragon.sys.intra> <1140052865.2302.64.camel@host-81-191-138-132.bluecom.no> <1140060379.21111.145.camel@dragon.sys.intra> <1140078535.4651.84.camel@dragon.sys.intra> <1140157902.3229.32.camel@dragon.sys.intra> <1140442863.3357.4.camel@orbit.scot.redhat.com> Message-ID: <1140451864.2384.81.camel@dragon.sys.intra> 'Ello, On Mon, 2006-02-20 at 08:41 -0500, Stephen C. Tweedie wrote: > > ------------[ cut here ]------------ > > kernel BUG at include/asm/xor.h:633! > > invalid opcode: 0000 [#1] > > That was supposed to be fixed (bug 177644); I'll chase this up and see > what's happening here. Cheers, just tried as of a few minutes ago and it's still with me.. kernel BUG at include/asm/xor.h:633! invalid opcode: 0000 [#1] SMP Modules linked in: xor raid1 raid0 xennet sr_mod sd_mod scsi_mod cdrom squashfs loop nfs nfs_acl lockd sunrpc vfat fat cramfs CPU: 0 After install was done there were also a few errors on start up (something about /dev/map ). > > 2) Ridiculously slow : 4 hours for a guest install of ?500mb. No > > identifiable host problem. I'm trying to do a network install and the > > instance running right now is doing less than 1 byte/sec according to > > "xm top". Just had it complete an install in an hour. Which is better. Ran some tests. wget over local net ( layer 2 switched no routing hops ) of openoffice-core RPM (77MB) : 100%[====================================>] 80,504,759 1.52M/s ETA 00:00 932.47 KB/s The same test from domain-0 : 100%[=================================================================================================================>] 80,504,759 10.03M/s ETA 00:00 10.40 MB/s. That's a very big difference. Normally I'd say it was duplex problem but I can't check that because of this : [root at localhost ~]# ethtool eth0 Settings for eth0: No data available > > > 3) Install crashes out at random points into install : > > > > Traceback (most recent call last): File > > > > "/usr/bin/anaconda", line 1210, in ? > > > > > > > > handleException(dispatch, intf, sys.exc_info()) > ... > > > > return _snack.reflow(text, width, flexDown, flexUp) > > > > > > > > TypeError: argument 1 must be string without null bytes, not str > > > > install exited > > > > abnormally > > Looks like an anaconda bug; could you file a bug report, please? Sure, will try and reproduce. You know, I think it happened last week with two guest installs at the same time. Will check. Cheers, From hughsient at gmail.com Mon Feb 20 16:24:27 2006 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 20 Feb 2006 16:24:27 +0000 Subject: torrent page? In-Reply-To: <43F9E01D.7030009@mindspring.com> References: <43F9DE63.5030803@mindspring.com> <43F9E01D.7030009@mindspring.com> Message-ID: <1140452667.11751.6.camel@localhost.localdomain> On Mon, 2006-02-20 at 10:28 -0500, Richard Hally wrote: > Richard Hally wrote: > > Anyone have an idea when this page will be updated for test3? > > > > http://torrent.fedoraproject.org/ > > > perfect timing! it is updated now. thanks I'm confused. Source: http://fedora.redhat.com/About/schedule/ 22 February 2006 test3 release, translation build freeze (builds completed) Do we get an early treat or something? Richard. From katzj at redhat.com Mon Feb 20 16:33:08 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 20 Feb 2006 11:33:08 -0500 Subject: Yum and SRPMs In-Reply-To: References: <1133079326.2854.1.camel@entropy> <20051128124649.GB29992@jadzia.bu.edu> <1133185654.21208.124.camel@cutter> <6280325c0511280703v2c514df8p63c31ca9cf06def7@mail.gmail.com> <1133190580.6952.0.camel@cutter> <604aa7910511280719l59f4921bja4c15e160cfb4e77@mail.gmail.com> <1133195955.16284.1.camel@weasel.turre.laiskiainen.org> <604aa7910511280856g3f043934g4c7da09e83ed181a@mail.gmail.com> <1140126778.2437.23.camel@ender> Message-ID: <1140453188.2573.1.camel@bree.local.net> On Mon, 2006-02-20 at 10:09 +0100, Rudolf Kastl wrote: > will the .repo files for the debug packages be available in the fedora > release package? > I agree that it should be turned off by default but still it should be > available, especially to simplify debugging with end users. Yes -- we're probably going to go with repos that are, eg, core core-debuginfo core-sources And similar for extras*. Jeremy From alan at redhat.com Mon Feb 20 16:40:29 2006 From: alan at redhat.com (Alan Cox) Date: Mon, 20 Feb 2006 11:40:29 -0500 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <1140451843.21764.593.camel@mccallum.corsepiu.local> References: <16330.217.33.199.77.1140444103.squirrel@mauro.ezplanet.net> <20060220145632.GD2861@free.fr> <1140448921.21764.589.camel@mccallum.corsepiu.local> <20060220153533.GB29559@devserv.devel.redhat.com> <1140451843.21764.593.camel@mccallum.corsepiu.local> Message-ID: <20060220164029.GA28228@devserv.devel.redhat.com> On Mon, Feb 20, 2006 at 05:10:43PM +0100, Ralf Corsepius wrote: > > OpenMotif is not free software by the FSF test. You can't for example use it > > with proprietary Nvidia drivers loaded. > > Only if you consider Nvidia's drivers to be integral part of the kernel. > I consider them to be optional add-ons/plug-ins. I asked the open group long ago and the email reply I got was to the contrary From bruno at wolff.to Mon Feb 20 16:55:27 2006 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 20 Feb 2006 10:55:27 -0600 Subject: torrent page? In-Reply-To: <1140452667.11751.6.camel@localhost.localdomain> References: <43F9DE63.5030803@mindspring.com> <43F9E01D.7030009@mindspring.com> <1140452667.11751.6.camel@localhost.localdomain> Message-ID: <20060220165527.GA27390@wolff.to> On Mon, Feb 20, 2006 at 16:24:27 +0000, Richard Hughes wrote: > On Mon, 2006-02-20 at 10:28 -0500, Richard Hally wrote: > > Richard Hally wrote: > > > Anyone have an idea when this page will be updated for test3? > > > > > > http://torrent.fedoraproject.org/ > > > > > perfect timing! it is updated now. thanks > > I'm confused. > > Source: http://fedora.redhat.com/About/schedule/ > > 22 February 2006 test3 release, translation build freeze (builds > completed) > > Do we get an early treat or something? I suspect the idea is to encourage bit torrent downloading to save bandwidth. They probably had to get things ready today anyway, so that public mirrors could have copies by Wednesdays. By letting people use bit torrent early they will reduce the spike on the ftp servers Wednesday. From sct at redhat.com Mon Feb 20 16:50:53 2006 From: sct at redhat.com (Stephen C. Tweedie) Date: Mon, 20 Feb 2006 11:50:53 -0500 Subject: Xen issues - Was Xen network performance problem during kickstart. In-Reply-To: <1140442863.3357.4.camel@orbit.scot.redhat.com> References: <1139987549.21111.68.camel@dragon.sys.intra> <1140052865.2302.64.camel@host-81-191-138-132.bluecom.no> <1140060379.21111.145.camel@dragon.sys.intra> <1140078535.4651.84.camel@dragon.sys.intra> <1140157902.3229.32.camel@dragon.sys.intra> <1140442863.3357.4.camel@orbit.scot.redhat.com> Message-ID: <1140454254.3357.22.camel@orbit.scot.redhat.com> Hi, On Mon, 2006-02-20 at 08:41 -0500, Stephen C. Tweedie wrote: > > ------------[ cut here ]------------ > > kernel BUG at include/asm/xor.h:633! > > invalid opcode: 0000 [#1] > > That was supposed to be fixed (bug 177644); I'll chase this up and see > what's happening here. I can't reproduce this. Are you sure you're running the 1955 kernel on both the dom0 and the domU, and the latest hypervisor from that dom0? Thanks, Stephen From sct at redhat.com Mon Feb 20 16:56:01 2006 From: sct at redhat.com (Stephen C. Tweedie) Date: Mon, 20 Feb 2006 11:56:01 -0500 Subject: Xen issues - Was Xen network performance problem during kickstart. In-Reply-To: <1140451864.2384.81.camel@dragon.sys.intra> References: <1139987549.21111.68.camel@dragon.sys.intra> <1140052865.2302.64.camel@host-81-191-138-132.bluecom.no> <1140060379.21111.145.camel@dragon.sys.intra> <1140078535.4651.84.camel@dragon.sys.intra> <1140157902.3229.32.camel@dragon.sys.intra> <1140442863.3357.4.camel@orbit.scot.redhat.com> <1140451864.2384.81.camel@dragon.sys.intra> Message-ID: <1140454561.3357.28.camel@orbit.scot.redhat.com> Hi, On Tue, 2006-02-21 at 01:11 +0900, Naoki wrote: > On Mon, 2006-02-20 at 08:41 -0500, Stephen C. Tweedie wrote: > > > ------------[ cut here ]------------ > > > kernel BUG at include/asm/xor.h:633! > > > invalid opcode: 0000 [#1] > > > > That was supposed to be fixed (bug 177644); I'll chase this up and see > > what's happening here. > > Cheers, just tried as of a few minutes ago and it's still with me.. I've just tried too, but can't reproduce. Are you sure you're running the 1955 kernel in both dom0 and domU, and the hypervisor from that dom0? > After install was done there were also a few errors on start up > (something about /dev/map ). Details would be helpful. :-) > Just had it complete an install in an hour. Which is better. Ran some > tests. > > wget over local net ( layer 2 switched no routing hops ) of > openoffice-core RPM (77MB) : > > 100%[====================================>] 80,504,759 1.52M/s > ETA 00:00 > > 932.47 KB/s > > The same test from domain-0 : > > 100%[=================================================================================================================>] 80,504,759 10.03M/s ETA 00:00 > > 10.40 MB/s. Chris Wright recently found a bug that could result in bad network performance amongst other things; but I'd expect that to affect dom0 as much as domU. What sort of config is this box? SMP/HT etc? > That's a very big difference. Normally I'd say it was duplex problem but > I can't check that because of this : > > [root at localhost ~]# ethtool eth0 > Settings for eth0: > No data available There's no such thing as an eth setting for domU: the device is emulated entirely in software. For dom0, there is still a real physical device, but the network scripts rename that to "peth0" and set up a virtual eth0 for bridging purposes. You should still be able to run ethtool on the peth0 device. Cheers, Stephen From rtlm10 at gmail.com Mon Feb 20 17:16:26 2006 From: rtlm10 at gmail.com (Russell Harrison) Date: Mon, 20 Feb 2006 12:16:26 -0500 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <49412.217.33.199.77.1140434038.squirrel@mauro.ezplanet.net> References: <49412.217.33.199.77.1140434038.squirrel@mauro.ezplanet.net> Message-ID: <1ed4a0130602200916o64a82391x81f5452c0ef11d4@mail.gmail.com> On 2/20/06, Kaimano wrote: > > > If I seriously need eclipse, I will go an get the latest JDK from Sun and > the latest eclipse from eclipse.org and run them as such, they install in > minutes and I can update them whenever available. FC5 has created a > massive and unnecessary overhead of work essential to keep up with the > latest releases. This is exactly the reason we decided to exclude eclipse from our RHEL 4 WS kickstarts. Engineering will want their own specialized version of eclipse anyway... Although I do like having it avalible as a rpm install for my own personal use. Assume an hipotetical scenario of an organization that rolled out Linux > desktop to 35000 workstations. The roadmap includes a desktop refresh in > no less than five years due to costs implications. This is why we went with RHEL instead of Fedora. I really miss my FC4 desktop from my last job but we're asking our users to work with RHEL so I'm using it as my desktop... The core e-Mail application is evolution 2.0. A bug is found on evolution > which requires upgrading to the latest 2.4. But ... evolution 2.4 requires > python 2.4, our installed base is on a distribution based on python 2.3 > (like FC2) which is... Yeah, we have to get Red Hat to supply patches for the existing 2.0 branch. It isn't optimal -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.mailhot at laposte.net Mon Feb 20 17:16:29 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 20 Feb 2006 18:16:29 +0100 (CET) Subject: The value of native java In-Reply-To: <1585.217.33.199.77.1140447917.squirrel@mauro.ezplanet.net> References: <48669.217.33.199.77.1140433968.squirrel@mauro.ezplanet.net> <3340.192.54.193.25.1140440068.squirrel@rousalka.dyndns.org> <40475.217.33.199.77.1140441677.squirrel@mauro.ezplanet.net> <56676.192.54.193.25.1140445934.squirrel@rousalka.dyndns.org> <1585.217.33.199.77.1140447917.squirrel@mauro.ezplanet.net> Message-ID: <34428.192.54.193.25.1140455789.squirrel@rousalka.dyndns.org> Le Lun 20 f?vrier 2006 16:05, Mauro Mozzarelli a ?crit : > Nicolas, > >> The GPL - not actual software code - is the single most important >> reason for the FSF influence in the Free Software world > Clearly we come from different cultural backgrounds. The licensing rules > are all an american thing that from my point of view can be perceived as > childish arguments. As we say here, MDR (http://www.journaldunet.com/encyclopedie/definition/379/54/22/mdr.shtml) First time a French man was accused of american bias. Should I feel offended? Regards, -- Nicolas Mailhot From sct at redhat.com Mon Feb 20 17:17:14 2006 From: sct at redhat.com (Stephen C. Tweedie) Date: Mon, 20 Feb 2006 12:17:14 -0500 Subject: Xen issues - Was Xen network performance problem during kickstart. In-Reply-To: <1140451864.2384.81.camel@dragon.sys.intra> References: <1139987549.21111.68.camel@dragon.sys.intra> <1140052865.2302.64.camel@host-81-191-138-132.bluecom.no> <1140060379.21111.145.camel@dragon.sys.intra> <1140078535.4651.84.camel@dragon.sys.intra> <1140157902.3229.32.camel@dragon.sys.intra> <1140442863.3357.4.camel@orbit.scot.redhat.com> <1140451864.2384.81.camel@dragon.sys.intra> Message-ID: <1140455834.3357.44.camel@orbit.scot.redhat.com> Hi, On Tue, 2006-02-21 at 01:11 +0900, Naoki wrote: > Cheers, just tried as of a few minutes ago and it's still with me.. > > kernel BUG at include/asm/xor.h:633! > invalid opcode: 0000 [#1] > SMP > Modules linked in: xor raid1 raid0 xennet sr_mod sd_mod scsi_mod cdrom > squashfs loop nfs nfs_acl lockd sunrpc vfat fat cramfs > CPU: 0 Working fine for me. Are you using 32- or 64-bit here? It may be that the 32-bit install is still broken, but 64-bit certainly doesn't show it for me. > > > 2) Ridiculously slow : 4 hours for a guest install of ?500mb. No > > > identifiable host problem. I'm trying to do a network install and the > > > instance running right now is doing less than 1 byte/sec according to > > > "xm top". > > Just had it complete an install in an hour. Which is better. Ran some > tests. I just did a graphical NFS domU install in about 20 minutes. That was with a 400MB guest, though --- install really likes a lot of memory, and you can often shrink the guest significantly after the install. Was your guest memory-constrained? > 932.47 KB/s Even 1MB/sec should be plenty fast enough for an NFS install. But my domU is showing >8MB/sec from a remote NFS mount; I've no idea why you are seeing such a difference between domU and dom0. Is this an otherwise-idle machine? --Stephen From jkeating at redhat.com Mon Feb 20 18:02:42 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 20 Feb 2006 10:02:42 -0800 Subject: Announcing Fedora Core 5 Test 3 Message-ID: <1140458562.2312.79.camel@ender> Forty-four years ago, John Hershel Glenn Jr. is successfully launched into space aboard the Friendship 7 spacecraft on the first orbital flight by an American astronaut. Russia had already sent two cosmonauts into orbit at this time. In the many following years Russian and America race each other for space superiority. Much later Russia and America have finally started cooperating in Earth's adventures into space. Competition is good, but collaboration can by so much better. Today, Open Source stands as one of the ultimate examples of collaboration. No boundaries, no borders, no barriers. As an example of this collaboration, we are proud to announce: Fedora Core 5 Test 3 Now Available ================================== The Fedora Project announces the third release of the Fedora Core 5 development cycle, available for the i386, x86_64, and PPC/PPC64 architectures. Beware that Test releases are recommended only for Linux experts/enthusiasts or for technology evaluation, as many parts are likely to be broken and the rate of change is rapid. http://fedora.redhat.com/About/schedule/ Final is scheduled for release March 15. This aggressive schedule makes vitally important your help in testing, reporting and suggesting fixes for bugs. Please direct bugs to http://bugzilla.redhat.com, Product Fedora Core, Version fc5test3. As always, be sure that your bug is not already fixed by updates and search for existing bugs before filing. http://fedoraproject.org/wiki/Core/ReleaseFreezeProcess/ During the continual freeze process, very few changes will be introduced. This is to prevent new bugs from surfacing and to ensure that Fedora Core 5 is the best release we can make it. Rawhide reports over the next three weeks should be very sparse. Please do test the few updates extensively. Thanks to all in the Fedora Project who have contributed to this release. Your continued efforts are what makes Fedora possible. Downloads ========= DVD, CD and network installation are available. Please read the Important Warnings below in this announcement for more details. http://torrent.fedoraproject.org/ The recommended method of download is via BitTorrent from this site. http://fedora.redhat.com/download/mirrors.html HTTP, FTP, and RSYNC downloads are available from Fedora Project mirrors listed above. Note that not all mirrors may be synced at this time. Notable Features of FC5 Test 3 ============================== * Xen, now with x86_64! * Package selection within the installer has been reenabled. * Rebuilt again on later gcc4.1 snapshot for performance and security * Hibernate should be functional on a wide variety of hardware again (use pm-hibernate to test) * PPC Install CDs are bootable once again * Unified SRPM set instead of one per arch * Lots of bugfixes from Test 2 release testing * 1600+ Extras packages conveniently available via yum http://fedora.redhat.com/docs/release-notes/ Latest version of release notes are available from here. (not yet uploaded, will be soon. Important Warnings ================== http://fedoraproject.org/wiki/FC5Test3CommonProblems Please see this page for an updated list of important notes for FC5test3 in order to avoid common problems and troubleshoot problems that you may see. Have fun testing this release, and enjoy the collaboration of Linux. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Mon Feb 20 19:23:08 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 20 Feb 2006 14:23:08 -0500 Subject: Questioning Pirut In-Reply-To: References: Message-ID: <1140463388.2573.45.camel@bree.local.net> On Fri, 2006-02-17 at 22:30 +0530, Kevin Verma wrote: > I will like to know your point of view why we really needed yet > another package manager, I understand that this one is created more to > adapt to Yum system. I will like to know your view if > system-config-packages could have been adapted to Yum as well ? pirut basically *is* just system-config-packages adapted to yum. Unfortunately, that largely required rewriting as all of the backend code was very specific to the implementation of hdlists, etc. While in the process of doing this, I've gone ahead and gotten one of the most common requests (a "view all" list mode) for s-c-packages implemented in the new code base. > And what are the projections with this tool ahead, I will also like to > point out that this tool is not working much as good enough on lower > resolution of 800x600 I have read it somewhere that the developer > accepting this tool does not look much eye candy yet, but can we > please have a peer view of the mock they have in mind this tool will > look like. I'll add making improvements for 800x600 to the list on my whiteboard. It shouldn't really require much in the way of major changes. And yeah, the graphics right now were my quick and dirty attempt at having something started. I should be sitting down with Diana at some point this week to get prettier ones. Jeremy From katzj at redhat.com Mon Feb 20 19:24:19 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 20 Feb 2006 14:24:19 -0500 Subject: Questioning Pirut In-Reply-To: <1140196937.17385.294.camel@xpc.home.erwinrol.com> References: <1140196937.17385.294.camel@xpc.home.erwinrol.com> Message-ID: <1140463459.2573.48.camel@bree.local.net> On Fri, 2006-02-17 at 18:22 +0100, Erwin Rol wrote: > On Fri, 2006-02-17 at 22:30 +0530, Kevin Verma wrote: > > And what are the projections with this tool ahead, I will also like to > > point out that this tool is not working much as good enough on lower > > resolution of 800x600 I have read it somewhere that the developer > > accepting this tool does not look much eye candy yet, but can we > > please have a peer view of the mock they have in mind this tool will > > look like. > > Pirut's GUI is just in a poor pre-alpha state, it hardly follows the > Gnome HIG, it can't do full screen, strange large font, the GUI > sometimes locks up when doing "networking" work, and the icons are just > terrible. If it is going to be shipped in FC5 like this it will just be > a plain embarrassment for Fedora. > > Of course that does not mean pirut doesn't have potential and certainly > doesn't mean the pirut developers are doing a poor job, it is simply > means pirut is not ready yet. By that logic, system-config-packages wasn't ready either (which pirut is replacing). I think that with pirut, we're in better shape * pirut does a better job of following the HIG than system-config-packages (please file specific cases where not). There are just some things in the HIG which can't make sense, eg, instant-apply :-) * The icons are placeholders and will definitely be fixed up before FC5 but rather than harass Diana multiple times, I wanted to get to a point where things are working pretty well instead of needing artwork multiple times. * I've tried to ensure interactivity as much as possible without pulling in threads. Unfortunately, some of the libraries being called into don't give any sort of progress feedback, and thus, long-term will probably require threading to give good interactivity. If there are specific places which are especially bad, please file them and I can see if there's a callback I'm not taking advantage of. We're already far better off here than we were with system-config-packages, though * pirut will actually be able to continue functioning after you've installed an update that has other requirements. For a fun way to break system-config-packages, install an updated, eg, krb5 package and then try to install the development group and watch it be unable to cope :-/ Jeremy From mandreiana.lists at gmail.com Mon Feb 20 19:27:30 2006 From: mandreiana.lists at gmail.com (Marius Andreiana) Date: Mon, 20 Feb 2006 21:27:30 +0200 Subject: closing older bug reports without looking = bad practice ? Message-ID: <1140463650.3252.30.camel@mariusa-ro.ro.oracle.com> Hi all, I've got a bunch of notices with FC5 test1 and test2 bugs being closed as there have been a lot of updates meanwhile. For me, as a tester which monitors some of the bugs and find some time once in a weekend to do some triage, this seemed plain rude. If there are too many bugs overwhelming developers then the cause should be addressed (better code with fewer bugs, which means more resources devoted to coding which are unavailable now) or find alternative solutions, where fedora testers could help. Closing all the reported bugs won't make them go away, but will make testers go away. With the current bugzilla setup, the number of reported bugs would have decreased as more testers do triage and see if they are still valid in rawhide, or they could confirm it until a developer finally looks at it, or the reporter might update it with new info. A practice from openoffice bugzilla could be borrowed - bugs reported by usual bugzilla acounts are by default UNCONFIRMED, and only fedora testers can set them to NEW. If there are too many bugs, a developer could ignore UNCONFIRMED ones. I also noticed Dave closes kernel bugs with each kernel release, asking people to retest. While this might save developers time, it could also leave real bugs closed as reporter might get tired of re-confirming a bug for 3 times. Take for example this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174968 In FC5test1, looks like the bttv driver had some problems, causing tvtuners to stop working. A few updates later, it worked again. The causes for not working and working again are unknown, therefore it could happen on every new release. Just cross fingers and hope for the best! To conclude, please don't close bug reports without researching them first. If Red Hat staff doesn't have time for it, please ask for triage help on fedora-test list, even with weekly themes, such as GNOME triage week (including searching for upstream bugs), kernel week etc - just post the link to the bugzilla query for all the required components. Thanks and looking forward for a better FC5 release! -- Marius Andreiana From katzj at redhat.com Mon Feb 20 19:24:31 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 20 Feb 2006 14:24:31 -0500 Subject: Questioning Pirut In-Reply-To: <6280325c0602190615h3727868i615a31844c6d4108@mail.gmail.com> References: <1140196937.17385.294.camel@xpc.home.erwinrol.com> <43F85B96.2010006@fedoraproject.org> <1140356730.17385.344.camel@xpc.home.erwinrol.com> <43F878E3.8050001@fedoraproject.org> <6280325c0602190615h3727868i615a31844c6d4108@mail.gmail.com> Message-ID: <1140463471.2573.50.camel@bree.local.net> On Mon, 2006-02-20 at 00:45 +1030, n0dalus wrote: > On 2/20/06, Rahul Sundaram wrote: > Making some nice icons for it shouldn't be too hard, but there are > some other issues with Pirut that are concerning. One is memory usage; > last time I looked Pirut used well over 100MB of system memory while > doing nothing. I am unable to see if that's improved at the moment > because Pirut now crashes with a backtrace on startup (not straight > away, it chews up 50MB of system memory first). Memory usage is already less than that of system-config-packages when dealing with a significantly larger body of packages. Which isn't to say it can't get better, but things are moving in the right direction. As for the backtrace, can you please ensure that it's fine in test3 (works on my laptop and all of my test systems) and if not, please file in bugzilla! Thanks, Jeremy From sundaram at fedoraproject.org Mon Feb 20 19:33:52 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 21 Feb 2006 01:03:52 +0530 Subject: closing older bug reports without looking = bad practice ? In-Reply-To: <1140463650.3252.30.camel@mariusa-ro.ro.oracle.com> References: <1140463650.3252.30.camel@mariusa-ro.ro.oracle.com> Message-ID: <43FA19A0.10904@fedoraproject.org> Marius Andreiana wrote: >Hi all, > >I've got a bunch of notices with FC5 test1 and test2 bugs being closed >as there have been a lot of updates meanwhile. For me, as a tester which >monitors some of the bugs and find some time once in a weekend to do >some triage, this seemed plain rude. > Yep. Just bad mistake from me. I am pretty much reopening all of the closed reports. Help in triaging is welcome though. fedora-triage-list and #fedora-bugs are there. Any friday interested testers can hop in . Refer to http://fedoraproject.org/wiki/BugZappers -- Rahul From katzj at redhat.com Mon Feb 20 19:25:16 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 20 Feb 2006 14:25:16 -0500 Subject: Questioning Pirut In-Reply-To: References: <1140197455.3317.4.camel@localhost.localdomain> Message-ID: <1140463518.2573.52.camel@bree.local.net> On Sat, 2006-02-18 at 02:04 -0500, Benjy Grogan wrote: > Aren't the days of libnotify over? Isn't D-Bus the replacement > for all system/console messages? Is libnotify still being > implemented as a back up? dbus is the mechanism for providing the message to the user session, but then you'd want to use libnotify for providing a nice visualization to the user. So the two are more complementary rather than one being a replacement for the other. Jeremy From katzj at redhat.com Mon Feb 20 19:25:26 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 20 Feb 2006 14:25:26 -0500 Subject: Questioning Pirut In-Reply-To: <43F6BB9D.6070703@rasmil.dk> References: <43F6BB9D.6070703@rasmil.dk> Message-ID: <1140463527.2573.53.camel@bree.local.net> Tim -- first off, my apologies for not getting back to your mail. Between travel and then trying to get test releases out, I just haven't managed to get enough time to sit down and type this up. On Sat, 2006-02-18 at 07:15 +0100, Tim Lauridsen wrote: > I have suggested to the developers to join forces and get Yum Extender > a.k.a yumex in shape to get into Core. > I takes time to make a good package manager gui and there are no need to > start from scratch. It's not really starting from scratch in this case, though, as we're leveraging a lot of the work that has had to be done for anaconda. As with system-config-packages before it, pirut has largely been driven by UI and other decisions made for anaconda so that we can provide a consistent interface around software selection during and after the installation process. > The current development release of yumex 0.99.9, currently in > extras-development, is in good shape and works in both > FC4 and rawhide. (and in RHEL 4 (with yum 2.4.x & CentOS 4.2) I think that yumex is great and provides what a lot of people are looking for, but at the same time, don't think that it provides the experience that we're looking to provide as a part of the installer, etc Jeremy From katzj at redhat.com Mon Feb 20 19:25:31 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 20 Feb 2006 14:25:31 -0500 Subject: Questioning Pirut In-Reply-To: <43F87B2E.6040509@fedoraproject.org> References: <43F6BB9D.6070703@rasmil.dk> <43F87B2E.6040509@fedoraproject.org> Message-ID: <1140463531.2573.54.camel@bree.local.net> On Sun, 2006-02-19 at 19:35 +0530, Rahul Sundaram wrote: > There is nothing called as "system-install-packages". Actually, there is. system-install-packages is the single package installer invoked when you double click on a package. It has similarly been pulled into the collection of software which is pirut. Jeremy From katzj at redhat.com Mon Feb 20 19:25:34 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 20 Feb 2006 14:25:34 -0500 Subject: Questioning Pirut In-Reply-To: <43F88CD1.7010302@vip.hr> References: <43F85B5D.50309@fedoraproject.org> <43F88CD1.7010302@vip.hr> Message-ID: <1140463534.2573.55.camel@bree.local.net> On Sun, 2006-02-19 at 16:20 +0100, Igor wrote: > But there is a thing I don't like with Pirut. Pirut will always look on > the internet first, instead of looking into the CD/DVD media. That's a > feature which dial-up users won't like very much. The > system-config-packages tool worked only with CD/DVD media, which is much > better approach for dial-up users. We've been working on moving the support needed for CD media into yum itself[1] so that all tools sitting on top of yum can use it. Once we're in good shape there, pirut will be able to take advantage of it. Jeremy [1] We have all of the code in anaconda -- at this point, it's a matter of making sure that it's suitably generic and pushing it downwards. From pertusus at free.fr Mon Feb 20 19:47:12 2006 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 20 Feb 2006 20:47:12 +0100 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <1140448921.21764.589.camel@mccallum.corsepiu.local> References: <16330.217.33.199.77.1140444103.squirrel@mauro.ezplanet.net> <20060220145632.GD2861@free.fr> <1140448921.21764.589.camel@mccallum.corsepiu.local> Message-ID: <20060220194712.GG2861@free.fr> On Mon, Feb 20, 2006 at 04:22:00PM +0100, Ralf Corsepius wrote: > On Mon, 2006-02-20 at 15:56 +0100, Patrice Dumas wrote: > > > But openmotif isn't even free software, > > Depends on your definition of "free software". Motif had been closed > source until several years ago, but times are a-changing: It is not an osi approved licence. I believe that it wouldn't qualify for being in extras. debian motif is based on lesstif. > # rpm -q --qf '%{LICENSE}\n' openmotif > Open Group Public License > > And lesstif, meanwhile is more or less without any practical importance, > anymore (It's not even part of FC or FE anymore) I was planning to package lesstif for extras, but it is not obvious, as it conflicts with openmotif, and isn't binary compatible. It doesn't mean that there are functionalities in openmotif that are used in motif apps that are in extras. Indeed, I haven't looked at the details, but it seems to me that all the motif apps in extras would be happy with lesstif motif. However, as there is no library versionning coordinated for lesstif and openmotif, I think it is hopeless. -- Pat From dwalsh at redhat.com Mon Feb 20 20:52:02 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 20 Feb 2006 15:52:02 -0500 Subject: Please disable the SELinux execstack/relro checks before FC5 final In-Reply-To: <43F8B6F8.20304@cornell.edu> References: <1140172961.2980.29.camel@laptopd505.fenrus.org> <1140186395.12655.245.camel@moss-spartans.epoch.ncsc.mil> <1140187398.12655.259.camel@moss-spartans.epoch.ncsc.mil> <1140207269.2980.57.camel@laptopd505.fenrus.org> <43F68B1B.5080002@redhat.com> <43F8B6F8.20304@cornell.edu> Message-ID: <43FA2BF2.4090304@redhat.com> Ivan Gyurdiev wrote: > >> If we cannot move the moz/ffox/tbird into their own domain then, yes, >> disable the checks for unconfined processes. But we should keep the >> tests for all programs which have their own domain. >> > Moz/ffox/tbird cannot be moved into their own domain until we have the > capability to launch content handling applications from within > firefox, and have them enter the proper domain. This is particularly > difficult, because some of those applications (i.e. openoffice) don't > have a domain at the moment (and creating one would be difficult). > That means firefox must be allowed to transition into > user_t/unconfined_t, which defeats any attempt at security. Launching > one application within another is the primary reason why the desktop > can't be confined. That is not entirely true. java, wine and mono all run in their own domain in targeted which is unconfined. I could do similar for thunderbird, firefox and freinds. We are not trying to confine these apps, but trying to confine the exec* apps to as few as possible. > > In the old strict policy firefox and mozilla were confined, and I > worked on the evolution and thunderbird policies over the summer. I > think the basic functionality was working, but those programs could > not be allowed to launch other apps. We need a trusted program to be > responsible for that, so that firefox can't transition into the > generic domain. > > There's other problems as well, including limiting those programs' > ability to write to the user home directory, and the top level /tmp > directory (what good does confining an application do, if it can still > overwrite all your important files, or steal your credit card info?). > There's marking of content as potentially hostile, and management of > that content. > > There's an effort to limit bonobo connections from firefox to > restricted domains only (no user_t/unconfined_t connections).... also > challenging, because there's so many things firefox talks to, and one > of them is sufficient to necessitate allowing communications channel > to user_t/unconfined_t. > > ============= > > Currently the firefox/moz/tbird/evolution policies have not been > ported yet to the new refpolicy. They also require the policies for > bonobo, orbit, gnome and other dekstop-related things (also not yet > ported). Even when they are ported, I doubt they would meet the needs > of targeted-policy users. From dwalsh at redhat.com Mon Feb 20 20:55:38 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 20 Feb 2006 15:55:38 -0500 Subject: Please disable the SELinux execstack/relro checks before FC5 final In-Reply-To: <43FA2BF2.4090304@redhat.com> References: <1140172961.2980.29.camel@laptopd505.fenrus.org> <1140186395.12655.245.camel@moss-spartans.epoch.ncsc.mil> <1140187398.12655.259.camel@moss-spartans.epoch.ncsc.mil> <1140207269.2980.57.camel@laptopd505.fenrus.org> <43F68B1B.5080002@redhat.com> <43F8B6F8.20304@cornell.edu> <43FA2BF2.4090304@redhat.com> Message-ID: <43FA2CCA.3060000@redhat.com> Anyways I think I will go with allow_execmem allow_execstack for FC5 on by default, all confined domains will not have this ability. For FC6 we will turn them off again but add a new unconfined type for firefox/thunderbird/evolution and freinds which will only allow them to use execstack. When ever you find an library that requires these privs please bugzilla them. Dan From seg at haxxed.com Mon Feb 20 21:16:48 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 20 Feb 2006 15:16:48 -0600 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <1140446102.2979.61.camel@laptopd505.fenrus.org> References: <49412.217.33.199.77.1140434038.squirrel@mauro.ezplanet.net> <1140435192.2979.45.camel@laptopd505.fenrus.org> <1140435779.29378.6.camel@xpc.home.erwinrol.com> <6f6293f10602200622v4c5d2179u1abd4f62dcce4f80@mail.gmail.com> <1140446102.2979.61.camel@laptopd505.fenrus.org> Message-ID: <43FA31C0.7050401@haxxed.com> Arjan van de Ven wrote: > On Mon, 2006-02-20 at 15:22 +0100, Felipe Alfaro Solana wrote: >>> but, but, than you have pay money, and we just switched to Linux >>> because everything is gratis ;-) >> I switched to Linux because of the freedom it gives to me, not only >> because it is gratis. You can also have a "gratis" version of any >> pirated software. > > > sigh... so this goes waaay off to an irrelevant tangent. My point was > that having a bug isn't a valid reason to upgrade to a major new version > (and all the dependency hell that that generates). The more right > solution is to fix the bug if it's important enough. If that's what you want, go use Debian stable and leave us alone plz kthx. From katzj at redhat.com Mon Feb 20 19:25:09 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 20 Feb 2006 14:25:09 -0500 Subject: Questioning Pirut In-Reply-To: <1140362196l.23688l.3l@athena.riede.org> References: <1140196937.17385.294.camel@xpc.home.erwinrol.com> <43F85B96.2010006@fedoraproject.org> <1140356730.17385.344.camel@xpc.home.erwinrol.com> <43F878E3.8050001@fedoraproject.org> <6280325c0602190615h3727868i615a31844c6d4108@mail.gmail.com> <43F880AC.606@fedoraproject.org> <1140362196l.23688l.3l@athena.riede.org> Message-ID: <1140463509.2573.51.camel@bree.local.net> On Sun, 2006-02-19 at 10:16 -0500, Willem Riede wrote: > On 02/19/2006 09:29:00 AM, Rahul Sundaram wrote: > > When you mention bugs, I would immediately like to see them followed bynice > > informative bug reports. When you mention UI issues, mockups wouldbe great > > contributions to help in the design of a better UI and whilehanging out on > > #fedora-devel you could always ping and talk to Jeremyand others over their > > plans for Pirut. Perfectionism is the root of allevils. > > Triggered by this thread, I just tried pirut for the first time, and while it > may lack polish, it certainly works. There's two observations that I'll be > happy to turn into bugzilla RFEs if so desired: > > 1. the packages added (or in this case removed) apparently are not added to > yum.log - I wish they were; Hrmm, I thought this was actually happening -- it's definitely intended to be. Looking, I see I forgot the call in both system-install-packages and pirut although I put it in pup. Added it to CVS and it'll be in the next build > 2. I wish the "details" that you've got 15 seconds to look at contain a list > of the packages that are actually going to be added / removed, not just the > ones drawn in for dependencies - I removed "dial-up networking", since I'm on > cable modem I figured I don't need them, and then saw minicom being erased, > which I wanted to keep (but not for dial-up). Easily enough to revert with > yum, but I should have been able to avoid it. This is something which I'm a bit open to discussion on -- I think that definitely for the case of updates (pup), the deps are something that you mostly want to accept and not have to actively accept. In the case of something like installing a single package, though, I can see more active acceptance making sense. The initial mockups had "apply" being more of a view that showed you what actions were about to occur and then requiring an active acceptance, more along the lines of what system-config-packages used to show. Adding back something like that (although probably as a dialog rather than a top-level view) is definitely something that could be done if it would be thought to make things better. Jeremy From jspaleta at gmail.com Mon Feb 20 21:55:58 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 20 Feb 2006 16:55:58 -0500 Subject: Questioning Pirut In-Reply-To: <1140463509.2573.51.camel@bree.local.net> References: <1140196937.17385.294.camel@xpc.home.erwinrol.com> <43F85B96.2010006@fedoraproject.org> <1140356730.17385.344.camel@xpc.home.erwinrol.com> <43F878E3.8050001@fedoraproject.org> <6280325c0602190615h3727868i615a31844c6d4108@mail.gmail.com> <43F880AC.606@fedoraproject.org> <1140362196l.23688l.3l@athena.riede.org> <1140463509.2573.51.camel@bree.local.net> Message-ID: <604aa7910602201355x61b217a6qfa63849bfd2023@mail.gmail.com> On 2/20/06, Jeremy Katz wrote: > This is something which I'm a bit open to discussion on -- I think that > definitely for the case of updates (pup), the deps are something that > you mostly want to accept and not have to actively accept. updates involving normal dep resolution maybe... but obsoletes which are causing a removal as part of an update? New packages installed which are needed by an update of an existing package? or updates due to epoch inflation? Do you want that to happen without a review step? I personally consider these package update paths abnormal and consider reviewing these actions part of due-diligence. And beyond pup.. into the realm of pirut functionality where whole groups of packages can be removed. You most certaintly want a review/accept step. I don't care how well you well think you have named a group and how consistently and intuitively you have filled it with members, there will be some divergence in the userbase over expectations as to what should be removed on group removal. And removing groups of packages via pirut without a review/accept stage is going to lead to confusion when functionality is removed that users didn't expect to be removed via group level removal operations. I would say any removal action needs to have a review/accept stage. -jef"can't wait to test how pirut handles group removals when core groups are extended by 3rd party repo group definitions which make the filesystem member package a member of every defined group. Correction... I can't wait to users find my 3rd party repo that makes filesystem a member of every defined Core group"spaleta From katzj at redhat.com Mon Feb 20 22:18:17 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 20 Feb 2006 17:18:17 -0500 Subject: Questioning Pirut In-Reply-To: <604aa7910602201355x61b217a6qfa63849bfd2023@mail.gmail.com> References: <1140196937.17385.294.camel@xpc.home.erwinrol.com> <43F85B96.2010006@fedoraproject.org> <1140356730.17385.344.camel@xpc.home.erwinrol.com> <43F878E3.8050001@fedoraproject.org> <6280325c0602190615h3727868i615a31844c6d4108@mail.gmail.com> <43F880AC.606@fedoraproject.org> <1140362196l.23688l.3l@athena.riede.org> <1140463509.2573.51.camel@bree.local.net> <604aa7910602201355x61b217a6qfa63849bfd2023@mail.gmail.com> Message-ID: <1140473897.3656.16.camel@orodruin.boston.redhat.com> On Mon, 2006-02-20 at 16:55 -0500, Jeff Spaleta wrote: > On 2/20/06, Jeremy Katz wrote: > > This is something which I'm a bit open to discussion on -- I think that > > definitely for the case of updates (pup), the deps are something that > > you mostly want to accept and not have to actively accept. > > updates involving normal dep resolution maybe... but obsoletes which > are causing a removal as part of an update? New packages installed > which are needed by an update of an existing package? or updates due > to epoch inflation? Do you want that to happen without a review step? > I personally consider these package update paths abnormal and consider > reviewing these actions part of due-diligence. Which is exactly why you get a dialog to give you the details if you want, but the vast majority of people aren't going to really want to deal with them. For pup, this seems to be working out pretty well > And beyond pup.. into the realm of pirut functionality where whole > groups of packages can be removed. You most certaintly want a > review/accept step. I don't care how well you well think you have > named a group and how consistently and intuitively you have filled it > with members, there will be some divergence in the userbase over > expectations as to what should be removed on group removal. And > removing groups of packages via pirut without a review/accept stage is > going to lead to confusion when functionality is removed that users > didn't expect to be removed via group level removal operations. I > would say any removal action needs to have a review/accept stage. Maybe go read the last paragraph of my mail? Like I said, something like this for the pirut case could make a reasonable amount of sense. Going back to a dialog much like the one from system-config-packages where you get something like (excuse my bad ascii art) ---------------------------------- | Going to install X packages | | Going to remove Y packages | | v Details | | [Cancel] [OK] | ---------------------------------- isn't at all hard to do. And thinking about things like group removal, I can see where it makes sense to bring this sort of thing back. The question is mostly around whether there's a better way to present the information > -jef"can't wait to test how pirut handles group removals when core > groups are extended by 3rd party repo group definitions which make the > filesystem member package a member of every defined group. > Correction... > I can't wait to users find my 3rd party repo that makes filesystem a > member of every defined Core group"spaleta In system-config-packages, we had a nice little check to ensure that you weren't removing "too many" packages that also checked for some key packages and gave you a scary looking warning if you did. Jeremy From benjy.grogan at gmail.com Mon Feb 20 22:43:15 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Mon, 20 Feb 2006 17:43:15 -0500 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <43F9C905.60402@fedoraproject.org> References: <49412.217.33.199.77.1140434038.squirrel@mauro.ezplanet.net> <1140435192.2979.45.camel@laptopd505.fenrus.org> <1140435779.29378.6.camel@xpc.home.erwinrol.com> <19078.217.33.199.77.1140436567.squirrel@mauro.ezplanet.net> <43F9C4F6.5030700@mharris.ca> <65095.217.33.199.77.1140443222.squirrel@mauro.ezplanet.net> <43F9C905.60402@fedoraproject.org> Message-ID: On 2/20/06, Rahul Sundaram wrote: > > Mauro Mozzarelli wrote: > > >>Kaimano wrote: > >> > > >The concerns are about spending more time for planning and design in > order > >to move towards a really open platform, otherwise the risk is to end up > >with an open source so complicated to maintain that it would not make any > >difference if it was proprietary and secret. > > > > > How are you willing to help? I think this is the most interesting thing about open source. How do people get involved in open source projects? It would be great to hear some of the stories. I'm sure there are many more people out there who would like to help and have the technical wherewithal to help but simply can't find a way to get started. I'd like to hear about people who in the last two or three years got involved in a certain project. I realize there are those who have been around for ten or more years and actually started some of the projects. But how are newcomers helping out in software development? Benji -------------- next part -------------- An HTML attachment was scrubbed... URL: From wrrhdev at riede.org Mon Feb 20 23:56:55 2006 From: wrrhdev at riede.org (Willem Riede) Date: Mon, 20 Feb 2006 18:56:55 -0500 Subject: Questioning Pirut In-Reply-To: <1140473897.3656.16.camel@orodruin.boston.redhat.com> (from katzj@redhat.com on Mon Feb 20 17:18:17 2006) References: <1140196937.17385.294.camel@xpc.home.erwinrol.com> <43F85B96.2010006@fedoraproject.org> <1140356730.17385.344.camel@xpc.home.erwinrol.com> <43F878E3.8050001@fedoraproject.org> <6280325c0602190615h3727868i615a31844c6d4108@mail.gmail.com> <43F880AC.606@fedoraproject.org> <1140362196l.23688l.3l@athena.riede.org> <1140463509.2573.51.camel@bree.local.net> <604aa7910602201355x61b217a6qfa63849bfd2023@mail.gmail.com> <1140473897.3656.16.camel@orodruin.boston.redhat.com> Message-ID: <1140479815l.15302l.0l@athena.riede.org> On 02/20/2006 05:18:17 PM, Jeremy Katz wrote: > > Maybe go read the last paragraph of my mail? Like I said, something > like this for the pirut case could make a reasonable amount of sense. > Going back to a dialog much like the one from system-config-packages > where you get something like (excuse my bad ascii art) > ---------------------------------- > | Going to install X packages | > | Going to remove Y packages | > | v Details | > | [Cancel] [OK] | > ---------------------------------- > > isn't at all hard to do. And thinking about things like group removal, > I can see where it makes sense to bring this sort of thing back. The > question is mostly around whether there's a better way to present the > information Group removal is exactly what I brought up yesterday. I would be satisfied with the above mockup, provided that the screen that comes up with details gives the apportunity to toggle the selection of individual packages in the group - dependencies permitting of course (one option is to gray out with package locked if required by another package; or ripple through to dependants, where if I toggle off a package that others depend on those get deselected too). Group install should have the similar capability. I may not want the exact set that is defined in comps. Thanks, Willem Riede. From dax at gurulabs.com Tue Feb 21 05:31:32 2006 From: dax at gurulabs.com (Dax Kelson) Date: Mon, 20 Feb 2006 22:31:32 -0700 Subject: FC5 test3 -- dmraid broken? Message-ID: <1140499892.3430.13.camel@mentorng.gurulabs.com> Tonight I tried installing FC5 test3 on my fake nforce4 RAID box. Anaconda and the install completed OK with LVM on top of my dmraid mirror. However, after the install finishes when the system tries to boot the kernel/initramfs can't find any LVM PVs and can't activate VolGroup00 and then it panics. I tried this twice, once with the XEN kernel and one without. Same results with the behavior difference of the XEN kernel auto-rebooting after it can't finding the LVM PVs. When I boot into the rescue environment the dmraid is activated and LVM comes up no problem. In the rescue environment I inspected the init script inside the initrd. It appears fine, maybe I've missed something. Here it is: #!/bin/nash mount -t proc /proc /proc setquiet echo Mounting proc filesystem echo Mounting sysfs filesystem mount -t sysfs /sys /sys echo Creating /dev mount -o mode=0755 -t tmpfs /dev /dev mkdir /dev/pts mount -t devpts -o gid=5,mode=620 /dev/pts /dev/pts mkdir /dev/shm mkdir /dev/mapper echo Creating initial device nodes mknod /dev/ram0 b 1 0 mknod /dev/ram1 b 1 1 mknod /dev/ram b 1 1 mknod /dev/null c 1 3 mknod /dev/zero c 1 5 mknod /dev/systty c 4 0 mknod /dev/tty c 5 0 mknod /dev/console c 5 1 mknod /dev/ptmx c 5 2 mknod /dev/rtc c 10 135 mknod /dev/tty0 c 4 0 mknod /dev/tty1 c 4 1 mknod /dev/tty2 c 4 2 mknod /dev/tty3 c 4 3 mknod /dev/tty4 c 4 4 mknod /dev/tty5 c 4 5 mknod /dev/tty6 c 4 6 mknod /dev/tty7 c 4 7 mknod /dev/tty8 c 4 8 mknod /dev/tty9 c 4 9 mknod /dev/tty10 c 4 10 mknod /dev/tty11 c 4 11 mknod /dev/tty12 c 4 12 mknod /dev/ttyS0 c 4 64 mknod /dev/ttyS1 c 4 65 mknod /dev/ttyS2 c 4 66 mknod /dev/ttyS3 c 4 67 echo Setting up hotplug. hotplug echo Creating block device nodes. mkblkdevs echo "Loading scsi_mod.ko module" insmod /lib/scsi_mod.ko echo "Loading sd_mod.ko module" insmod /lib/sd_mod.ko echo "Loading libata.ko module" insmod /lib/libata.ko echo "Loading sata_nv.ko module" insmod /lib/sata_nv.ko echo "Loading jbd.ko module" insmod /lib/jbd.ko echo "Loading ext3.ko module" insmod /lib/ext3.ko echo "Loading dm-mod.ko module" insmod /lib/dm-mod.ko echo "Loading dm-mirror.ko module" insmod /lib/dm-mirror.ko echo "Loading dm-zero.ko module" insmod /lib/dm-zero.ko echo "Loading dm-snapshot.ko module" insmod /lib/dm-snapshot.ko echo Making device-mapper control node mkdmnod mkblkdevs rmparts sda rmparts sdb dm create nvidia_hcddcidd 0 586114702 mirror core 2 64 nosync 2 8:16 0 8:0 0 dm partadd nvidia_hcddcidd echo Scanning logical volumes lvm vgscan --ignorelockingfailure echo Activating logical volumes lvm vgchange -ay --ignorelockingfailure VolGroup00 resume /dev/VolGroup00/LogVol01 echo Creating root device. mkrootdev -t ext3 -o defaults,ro /dev/VolGroup00/LogVol00 echo Mounting root filesystem. mount /sysroot echo Setting up other filesystems. setuproot echo Switching to new root and running init. switchroot From bojan at rexursive.com Tue Feb 21 05:47:15 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 21 Feb 2006 16:47:15 +1100 Subject: FC5T3 on x86_64 Message-ID: <20060221164715.tpn9aadoisco88wc@imp.rexursive.com> I'm trying to upgrade an FC4 box (x86_64) to FC5T3, but I'm getting an error just after "Preparing transaction from the installation media". Basically, the message is something like "We should really show you the debug info here, but we'll just fail instead." On VT3 I can see that there are file conflicts between packages from FC4 and FC5T3, namely for xpdf, xorg-x11-devel, python-devel, vim-common and e2fsprogs. Not sure if those are harmless or if they are actually causing the install to stop. The box is running RAID1 (md) and LVM - not sure if that's somehow related. It also has 32 bit libs installed. -- Bojan From bojan at rexursive.com Tue Feb 21 05:50:08 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 21 Feb 2006 16:50:08 +1100 Subject: FC5T3 on x86_64 In-Reply-To: <20060221164715.tpn9aadoisco88wc@imp.rexursive.com> References: <20060221164715.tpn9aadoisco88wc@imp.rexursive.com> Message-ID: <20060221165008.oc4a767pwss840ks@imp.rexursive.com> Quoting Bojan Smojver : > The box is running RAID1 (md) and LVM - not sure if that's somehow > related. It also has 32 bit libs installed. I'll attach lspci from FC4 here, for reference. -- Bojan -------------- next part -------------- 00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) Subsystem: Hewlett-Packard Company: Unknown device 1500 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2) Subsystem: Hewlett-Packard Company: Unknown device 1500 Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3) Subsystem: Hewlett-Packard Company: Unknown device 1500 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable+ Address: 00000000fee00000 Data: 40b9 Capabilities: [58] HyperTransport: MSI Mapping Capabilities: [80] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <512ns, L1 <4us Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s, Port 0 Link: Latency L0s <512ns, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x16 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise- Slot: Number 1, PowerLimit 75.000000 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Off, PwrInd On, Power- Root: Correctable- Non-Fatal- Fatal- PME- Capabilities: [100] Virtual Channel 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- References: <1140196937.17385.294.camel@xpc.home.erwinrol.com> <1140463459.2573.48.camel@bree.local.net> Message-ID: <43FABCC4.7090101@nicubunu.ro> Jeremy Katz wrote: > > * pirut does a better job of following the HIG than > system-config-packages (please file specific cases where not). There > are just some things in the HIG which can't make sense, eg, > instant-apply :-) By NOT using instant-apply here you are conforming to the HIG, as the installation even of a single package will take more than one second: "Do not make the user press an OK or Apply button to make the changes happen, unless either: [...] the change will take more than about one second to apply, in which case applying the change immediately could make the system feel slow or unresponsive" -- nicu my hats collection: http://fedora.nicubunu.ro/hats Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From enrico.scholz at informatik.tu-chemnitz.de Tue Feb 21 07:30:18 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 21 Feb 2006 08:30:18 +0100 Subject: dietlibc compilation error in PPC In-Reply-To: <8764ndvu0m.fsf@kosh.bigo.ensc.de> (Enrico Scholz's message of "Sat, 18 Feb 2006 11:30:33 +0100") References: <8764ndvu0m.fsf@kosh.bigo.ensc.de> Message-ID: <87r75xb245.fsf@kosh.bigo.ensc.de> enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) writes: > compilation of dietlibc in devel branch fails on PPC machine at code > like > > | 36 #define B0 + 1.0l/ 6/ 1/ 2 > | ... > | 50 static const double coeff[] = { B0, ... }; > > > The error message is > > | libm/gamma.c:50: error: initializer element is not constant > | libm/gamma.c:50: error: (near initialization for 'coeff[0]') ok, issue seems to be unexplainable. So, dietlibc and depending packages got an 'ExcludeArch: ppc' until somebody tells me the reason resp. gcc gets fixed. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 482 bytes Desc: not available URL: From naoki at valuecommerce.com Tue Feb 21 07:48:54 2006 From: naoki at valuecommerce.com (Naoki) Date: Tue, 21 Feb 2006 16:48:54 +0900 Subject: Xen issues - Was Xen network performance problem during kickstart. In-Reply-To: <1140451864.2384.81.camel@dragon.sys.intra> References: <1139987549.21111.68.camel@dragon.sys.intra> <1140052865.2302.64.camel@host-81-191-138-132.bluecom.no> <1140060379.21111.145.camel@dragon.sys.intra> <1140078535.4651.84.camel@dragon.sys.intra> <1140157902.3229.32.camel@dragon.sys.intra> <1140442863.3357.4.camel@orbit.scot.redhat.com> <1140451864.2384.81.camel@dragon.sys.intra> Message-ID: <1140508134.2384.126.camel@dragon.sys.intra> On the guest that I was running the transfer tests on this popped up sometime afterwards. [root at localhost ~]# BUG: soft lockup detected on CPU#0! Pid: 0, comm: swapper EIP: 0061:[] CPU: 0 EIP is at 0xc01040c7 EFLAGS: 00000246 Not tainted (2.6.15-1.1955_FC5guest) EAX: 00000000 EBX: 00000001 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: c02ea000 EBP: 00000020 DS: 007b ES: 007b CR0: 8005003b CR2: 003b4f34 CR3: 03389000 CR4: 00000600 [] xen_idle+0x59/0x68 [] cpu_idle+0x8b/0xa4 [] start_kernel+0x2ed/0x2f3 BUG: soft lockup detected on CPU#0! Pid: 5028, comm: zcat EIP: 0061:[] CPU: 0 EIP is at 0xc0104227 EFLAGS: 00000246 Not tainted (2.6.15-1.1955_FC5guest) EAX: 00030000 EBX: 00000000 ECX: 00000000 EDX: c1cfbfbc ESI: 00000000 EDI: c0110c11 EBP: 00000004 DS: 007b ES: 007b CR0: 8005003b CR2: 0804eab0 CR3: 024be000 CR4: 00000600 [] force_evtchn_callback+0xa/0xc [] do_page_fault+0xa7/0x633 [] do_page_fault+0x0/0x633 [] error_code+0x2b/0x30 BUG: soft lockup detected on CPU#0! Pid: 5452, comm: makewhatis EIP: 0073:[<002ccf13>] CPU: 0 EIP is at 0x2ccf13 ESP: 007b:bfa88b88 EFLAGS: 00000246 Not tainted (2.6.15-1.1955_FC5guest) EAX: 09e81688 EBX: 0038dff4 ECX: 00000001 EDX: 00000000 ESI: 0038f120 EDI: 09e810c8 EBP: bfa88bb8 DS: 007b ES: 007b CR0: 8005003b CR2: 09e70050 CR3: 01f15000 CR4: 00000600 BUG: soft lockup detected on CPU#0! Pid: 1714, comm: makewhatis EIP: 0061:[] CPU: 0 EIP is at 0xc0104227 EFLAGS: 00000246 Not tainted (2.6.15-1.1955_FC5guest) EAX: 00030000 EBX: 00000000 ECX: 00000000 EDX: c3375fbc ESI: 09e81ce8 EDI: c0110c11 EBP: 00000007 DS: 007b ES: 007b CR0: 8005003b CR2: 09e81cf0 CR3: 02a3b000 CR4: 00000600 [] force_evtchn_callback+0xa/0xc [] do_page_fault+0xa7/0x633 [] do_page_fault+0x0/0x633 [] error_code+0x2b/0x30 BUG: soft lockup detected on CPU#0! Pid: 6859, comm: makewhatis EIP: 0061:[] CPU: 0 EIP is at 0xc0104347 EFLAGS: 00000246 Not tainted (2.6.15-1.1955_FC5guest) EAX: 00000000 EBX: c1933de8 ECX: 00000001 EDX: 00000000 ESI: 00007ff0 EDI: c1d78004 EBP: c1d78004 DS: 007b ES: 007b CR0: 8005003b CR2: b7f8ccdd CR3: 019d5000 CR4: 00000600 [] xen_pgd_pin+0x38/0x4a [] __pgd_pin+0x1d/0x31 [] mm_pin+0x18/0x21 [] flush_old_exec+0x626/0x91e [] vfs_read+0xf6/0x136 [] kernel_read+0x39/0x42 [] load_elf_binary+0x307/0x15bc [] load_elf_binary+0x4a8/0x15bc [] get_page_from_freelist+0x99/0x396 [] get_page_from_freelist+0x24d/0x396 [] copy_from_user+0x5c/0x90 [] copy_strings+0x167/0x1c0 [] load_elf_binary+0x0/0x15bc [] search_binary_handler+0x90/0x21b [] do_execve+0x15f/0x1fc [] sys_execve+0x2c/0x6d [] syscall_call+0x7/0xb BUG: soft lockup detected on CPU#0! Pid: 28272, comm: gawk EIP: 0061:[] CPU: 0 EIP is at vma_adjust+0x1e6/0x3bc EFLAGS: 00000246 Not tainted (2.6.15-1.1955_FC5guest) EAX: c03c0650 EBX: c2ac3828 ECX: cdbd9fc4 EDX: 00000000 ESI: 00000000 EDI: c33da6fc EBP: 00000000 DS: 007b ES: 007b CR0: 80050033 CR2: 0901f04c CR3: 0e2e7000 CR4: 00000600 [] _spin_unlock+0x6/0x8 [] __handle_mm_fault+0x931/0x959 [] vma_merge+0xd1/0x155 [] do_brk+0x198/0x255 [] sys_brk+0xcf/0xfe [] syscall_call+0x7/0xb BUG: soft lockup detected on CPU#0! Pid: 28426, comm: makewhatis EIP: 0061:[] CPU: 0 EIP is at 0xc0104345 EFLAGS: 00000246 Not tainted (2.6.15-1.1955_FC5guest) EAX: 0000001a EBX: c1991d84 ECX: 80000001 EDX: 00000000 ESI: 00007ff0 EDI: c1d78604 EBP: c1d78a04 DS: 007b ES: 007b CR0: 8005003b CR2: 002724f2 CR3: 019e9000 CR4: 00000600 [] xen_pgd_unpin+0x38/0x4a [] __pgd_unpin+0x10/0x32 [] mm_unpin+0x18/0x21 [] _arch_exit_mmap+0x14c/0x155 [] exit_mmap+0x19/0xee [] mmput+0x1e/0x93 [] flush_old_exec+0x6ef/0x91e [] vfs_read+0xf6/0x136 [] kernel_read+0x39/0x42 [] load_elf_binary+0x307/0x15bc [] load_elf_binary+0x4a8/0x15bc [] get_page_from_freelist+0x99/0x396 [] get_page_from_freelist+0x24d/0x396 [] copy_from_user+0x5c/0x90 [] copy_from_user+0x5c/0x90 [] copy_strings+0x167/0x1c0 [] load_elf_binary+0x0/0x15bc [] search_binary_handler+0x90/0x21b [] do_execve+0x15f/0x1fc [] sys_execve+0x2c/0x6d [] syscall_call+0x7/0xb BUG: soft lockup detected on CPU#0! Pid: 29678, comm: makewhatis EIP: 0061:[] CPU: 0 EIP is at poison_obj+0x1c/0x25 EFLAGS: 00000286 Not tainted (2.6.15-1.1955_FC5guest) EAX: 0000005a EBX: c18d9000 ECX: 00000000 EDX: 00001000 ESI: c0599ac0 EDI: c18da000 EBP: 000000d0 DS: 007b ES: 007b CR0: 8005003b CR2: b7f8ccdd CR3: 068af000 CR4: 00000600 [] cache_alloc_debugcheck_after+0x30/0xfb [] kmem_cache_alloc+0xca/0xd5 [] getname+0x18/0x9f [] getname+0x18/0x9f [] getname+0x18/0x9f [] __user_walk_fd+0xe/0x3a [] sys_faccessat+0x92/0x126 [] mntput_no_expire+0x14/0x75 [] audit_syscall_entry+0x10e/0x133 [] do_syscall_trace+0x112/0x15e [] sys_access+0xf/0x13 [] syscall_call+0x7/0xb BUG: soft lockup detected on CPU#0! Pid: 30063, comm: prelink EIP: 0061:[] CPU: 0 EIP is at _raw_spin_lock+0x4f/0xd9 EFLAGS: 00000246 Not tainted (2.6.15-1.1955_FC5guest) EAX: 00000001 EBX: c6c04000 ECX: cf21cb78 EDX: 00000004 ESI: cf21cba4 EDI: cf21cba4 EBP: cf42a000 DS: 007b ES: 007b CR0: 8005003b CR2: 00786000 CR3: 02d5f000 CR4: 00000600 [] _spin_lock+0x6/0x8 [] packet_rcv_spkt+0x156/0x226 [] netif_receive_skb+0x200/0x279 [] netif_poll+0x554/0x741 [xennet] [] net_rx_action+0xcd/0x201 [] __do_softirq+0x70/0xef [] do_softirq+0x40/0x67 [] do_IRQ+0x22/0x28 [] evtchn_do_upcall+0x63/0x9d [] hypervisor_callback+0x2c/0x34 BUG: soft lockup detected on CPU#0! Pid: 30063, comm: prelink EIP: 0061:[] CPU: 0 EIP is at neigh_lookup+0x33/0xa3 EFLAGS: 00000286 Not tainted (2.6.15-1.1955_FC5guest) EAX: c03df0e8 EBX: 00000001 ECX: df8982df EDX: 00000000 ESI: c02b50e0 EDI: cc74d030 EBP: 00000004 DS: 007b ES: 007b CR0: 8005003b CR2: b7da4000 CR3: 02d5f000 CR4: 00000600 [] arp_process+0x46b/0x536 [] cache_free_debugcheck+0x19a/0x1bc [] cache_free_debugcheck+0x1b4/0x1bc [] kfree_skbmem+0x65/0x69 [] cache_alloc_debugcheck_after+0xc1/0xfb [] cache_free_debugcheck+0x1b4/0x1bc [] kfree_skbmem+0x65/0x69 [] kmem_cache_free+0x3f/0x9c [] arp_rcv+0x10a/0x149 [] netif_receive_skb+0x22b/0x279 [] netif_poll+0x554/0x741 [xennet] [] net_rx_action+0xcd/0x201 [] __do_softirq+0x70/0xef [] do_softirq+0x40/0x67 [] do_IRQ+0x22/0x28 [] evtchn_do_upcall+0x63/0x9d [] hypervisor_callback+0x2c/0x34 [] packet_ioctl+0xbb/0xd3 [] force_evtchn_callback+0xa/0xc [] free_hot_cold_page+0xae/0x181 [] __pagevec_free+0x1a/0x24 [] release_pages+0x11f/0x162 [] __pagevec_release+0x18/0x23 [] truncate_inode_pages_range+0xca/0x278 [] truncate_inode_pages+0x15/0x1c [] reiserfs_delete_inode+0x40/0x10a [reiserfs] [] cache_free_debugcheck+0x1b4/0x1bc [] vfs_rename+0x3bf/0x3cf [] reiserfs_delete_inode+0x0/0x10a [reiserfs] [] generic_delete_inode+0xa7/0x119 [] dentry_iput+0x75/0x90 [] dput+0x151/0x169 [] sys_renameat+0x167/0x1bf [] sys_utime+0x109/0x125 [] cache_free_debugcheck+0x1b4/0x1bc [] audit_syscall_exit+0x27a/0x33e [] audit_syscall_entry+0x10e/0x133 [] do_syscall_trace+0x112/0x15e [] sys_rename+0x11/0x15 [] syscall_call+0x7/0xb BUG: soft lockup detected on CPU#0! Pid: 30997, comm: ld-linux.so.2 EIP: 0061:[] CPU: 0 EIP is at check_poison_obj+0x39/0x15d EFLAGS: 00000293 Not tainted (2.6.15-1.1955_FC5guest) EAX: 000000a5 EBX: ced5cdac ECX: ced5cdb0 EDX: ced5cd6b ESI: c05881c0 EDI: 0000002a EBP: 00000080 DS: 007b ES: 007b CR0: 8005003b CR2: b7f52000 CR3: 0b20d000 CR4: 00000600 [] file_update_time+0x2d/0x86 [] cache_alloc_debugcheck_after+0x22/0xfb [] __kmalloc_track_caller+0xfa/0x104 [] sys_writev+0x3b/0x97 [] do_readv_writev+0x5b/0x242 [] sys_writev+0x3b/0x97 [] pipe_write+0x0/0x2a [] audit_syscall_entry+0x10e/0x133 [] sys_writev+0x3b/0x97 [] syscall_call+0x7/0xb BUG: soft lockup detected on CPU#0! Pid: 31017, comm: ld-linux.so.2 EIP: 0073:[<002481d5>] CPU: 0 EIP is at 0x2481d5 ESP: 007b:bfef94fc EFLAGS: 00000246 Not tainted (2.6.15-1.1955_FC5guest) EAX: 007a50dc EBX: 00258fd8 ECX: b7ff22d0 EDX: 000001ab ESI: 00444ae8 EDI: 00000218 EBP: bfef9564 DS: 007b ES: 007b CR0: 8005003b CR2: 0078d2ec CR3: 08272000 CR4: 00000600 BUG: soft lockup detected on CPU#0! Pid: 0, comm: swapper EIP: 0061:[] CPU: 0 EIP is at 0xc01040c7 EFLAGS: 00000246 Not tainted (2.6.15-1.1955_FC5guest) EAX: 00000000 EBX: 00000001 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: c02ea000 EBP: 00000020 DS: 007b ES: 007b CR0: 8005003b CR2: 00388304 CR3: 02d5f000 CR4: 00000600 [] xen_idle+0x59/0x68 [] cpu_idle+0x8b/0xa4 [] start_kernel+0x2ed/0x2f3 BUG: soft lockup detected on CPU#0! Pid: 31079, comm: ld-linux.so.2 EIP: 0073:[<002484c3>] CPU: 0 EIP is at 0x2484c3 ESP: 007b:bfe382cc EFLAGS: 00000202 Not tainted (2.6.15-1.1955_FC5guest) EAX: 00000000 EBX: 00258fd8 ECX: 00000061 EDX: 0026cbb3 ESI: 6cbb5430 EDI: f0000000 EBP: bfe383dc DS: 007b ES: 007b CR0: 8005003b CR2: 00256798 CR3: 0767d000 CR4: 00000600 BUG: soft lockup detected on CPU#0! Pid: 30063, comm: prelink EIP: 0061:[] CPU: 0 EIP is at __copy_to_user_ll+0x3e/0xe2 EFLAGS: 00000216 Not tainted (2.6.15-1.1955_FC5guest) EAX: 5362646d EBX: cb830000 ECX: 00000ec0 EDX: 70720065 ESI: cb830140 EDI: 09f4766c EBP: c6c05ebc DS: 007b ES: 007b CR0: 8005003b CR2: 00ad1000 CR3: 02d5f000 CR4: 00000600 [] file_read_actor+0x60/0xd4 [] do_generic_mapping_read+0x1b0/0x490 [] __generic_file_aio_read+0x16b/0x1b3 [] file_read_actor+0x0/0xd4 [] generic_file_read+0xad/0xc3 [] do_filp_open+0x2d/0x35 [] autoremove_wake_function+0x0/0x3a [] _spin_lock+0x6/0x8 [] audit_syscall_entry+0x10e/0x133 [] vfs_read+0xa2/0x136 [] sys_pread64+0x43/0x5b [] syscall_call+0x7/0xb BUG: soft lockup detected on CPU#0! Pid: 31583, comm: ld-linux.so.2 EIP: 0061:[] CPU: 0 EIP is at file_update_time+0x61/0x86 EFLAGS: 00000246 Not tainted (2.6.15-1.1955_FC5guest) EAX: cfd4ddbc EBX: cfd4dd68 ECX: 38e79400 EDX: 43fa1ca6 ESI: 00000000 EDI: 0000000a EBP: c02a3900 DS: 007b ES: 007b CR0: 8005003b CR2: 00256798 CR3: 0969e000 CR4: 00000600 [] pipe_writev+0x365/0x389 [] do_readv_writev+0x150/0x242 [] pipe_write+0x0/0x2a [] sys_writev+0x3b/0x97 [] syscall_call+0x7/0xb INIT: version 2.86 reloading BUG: soft lockup detected on CPU#0! Pid: 0, comm: swapper EIP: 0061:[] CPU: 0 EIP is at 0xc01040c7 EFLAGS: 00000246 Not tainted (2.6.15-1.1955_FC5guest) EAX: 00000000 EBX: 00000001 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: c02ea000 EBP: 00000020 DS: 007b ES: 007b CR0: 8005003b CR2: 08652a74 CR3: 0fdde000 CR4: 00000600 [] xen_idle+0x59/0x68 [] cpu_idle+0x8b/0xa4 [] start_kernel+0x2ed/0x2f3 BUG: soft lockup detected on CPU#0! Pid: 0, comm: swapper EIP: 0061:[] CPU: 0 EIP is at 0xc01040c7 EFLAGS: 00200246 Not tainted (2.6.15-1.1955_FC5guest) EAX: 00000000 EBX: 00000001 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: c02ea000 EBP: 00000020 DS: 007b ES: 007b CR0: 8005003b CR2: b7da4000 CR3: 0de0c000 CR4: 00000600 [] xen_idle+0x59/0x68 [] cpu_idle+0x8b/0xa4 [] start_kernel+0x2ed/0x2f3 BUG: soft lockup detected on CPU#0! Pid: 0, comm: swapper EIP: 0061:[] CPU: 0 EIP is at 0xc01040c7 EFLAGS: 00200246 Not tainted (2.6.15-1.1955_FC5guest) EAX: 00000000 EBX: 00000001 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: c02ea000 EBP: 00000020 DS: 007b ES: 007b CR0: 8005003b CR2: 0016c9f8 CR3: 0de0c000 CR4: 00000600 [] xen_idle+0x59/0x68 [] cpu_idle+0x8b/0xa4 [] start_kernel+0x2ed/0x2f3 BUG: soft lockup detected on CPU#0! Pid: 1507, comm: sh EIP: 0061:[] CPU: 0 EIP is at check_poison_obj+0x3c/0x15d EFLAGS: 00000246 Not tainted (2.6.15-1.1955_FC5guest) EAX: 00000fa5 EBX: c9a6e000 ECX: c9a6e000 EDX: c9a6e06b ESI: c0599ac0 EDI: 000000a3 EBP: 00001000 DS: 007b ES: 007b CR0: 8005003b CR2: 080976c0 CR3: 05223000 CR4: 00000600 [] cache_alloc_debugcheck_after+0x22/0xfb [] kmem_cache_alloc+0xca/0xd5 [] getname+0x18/0x9f [] getname+0x18/0x9f [] getname+0x18/0x9f [] sys_execve+0xc/0x6d [] syscall_call+0x7/0xb From buildsys at redhat.com Tue Feb 21 08:26:35 2006 From: buildsys at redhat.com (Build System) Date: Tue, 21 Feb 2006 03:26:35 -0500 Subject: rawhide report: 20060221 changes Message-ID: <200602210826.k1L8QZw7013975@porkchop.devel.redhat.com> Removed package gnome-kerberos Updated Packages: authconfig-5.2.1-1 ------------------ * Mon Feb 20 2006 Tomas Mraz - 5.2.1-1 - don't crash in TUI when some options aren't set (#182151) * Fri Feb 03 2006 Tomas Mraz - 5.2.0-1 - redesigned GUI (#178112) - added man page for system-config-ac (#179584) - disable authentication of system accounts by network services by default, added option for changing that (#179009) - updated translations, new languages * Mon Jan 09 2006 Tomas Mraz - 5.1.2-1 - fixed regression when saving nsswitch.conf busybox-1:1.01-3 ---------------- chkfontpath-1.10.1-1 -------------------- * Thu Feb 16 2006 Mike A. Harris 1.10.1-1 - Implemented new --listfp option for bug (#153324). - Fix stderr output redirection bug in kill invocation (#176444). - Check return code from realloc() and exit on failure. control-center-1:2.13.92-1 -------------------------- * Wed Feb 15 2006 Matthias Clasen - 2.13.92-1 - Update to 2.13.92 * Fri Feb 10 2006 Jesse Keating - 1:2.13.91-1.1 - bump again for double-long bug on ppc(64) * Wed Feb 08 2006 Matthias Clasen - 2.13.91-1 - Update to 2.13.91 - Reenable Spanish help devhelp-0.11-3 -------------- findutils-1:4.2.27-4 -------------------- * Sun Feb 19 2006 Miloslav Trmac - 1:4.2.27-4 - Report the correct directory when hard link count is inconsistent (#182001) g-wrap-1.9.6-1 -------------- * Sat Feb 18 2006 Bill Nottingham 1.9.6-1 - update to 1.9.6, to fix incompatiblity with gcc-4.x - disable static libs gcc-4.1.0-0.29 -------------- * Sun Feb 19 2006 Jakub Jelinek 4.1.0-0.29 - update from gcc-4_1-branch (-r111179:111278) - PRs ada/13408, c++/26266, target/22209, target/26189 - fix ppc32 -fpic reload problem with extenddftf2 pattern (David Edelsohn, #181625, PR target/26350) - fix the PR middle-end/26334 patch * Fri Feb 17 2006 Jakub Jelinek 4.1.0-0.28 - update from gcc-4_1-branch (-r110978:111179) - PRs ada/20753, bootstrap/16787, bootstrap/26053, fortran/25806, libfortran/15234, libgfortran/25949, middle-end/25335, target/25259, target/26255 - fix ICE with shift by -1 (#181586, PR middle-end/26300) - merge gomp changes from trunk (-r110983:110984, -r111017:111018, -r111152:111153 and -r111204:111205) - PRs bootstrap/26161, fortran/26224, libgomp/25938, libgomp/25984 - don't define _REENTRANT in gthr*.h (#176278, PR libstdc++/11953) - define _REENTRANT if -pthread and _POSIX_SOURCE if -posix on s390{,x} and ia64 - fix ICE with register variable and __asm statement (#181731, PR middle-end/26334) glibc-2.3.90-38 --------------- * Fri Feb 17 2006 Jakub Jelinek 2.3.90-38 - update from CVS - robust mutexes rewrite gnome-panel-2.13.91-3 --------------------- * Sun Feb 19 2006 Ray Strode - 2.13.91-3 - bring back shutdown menu item gnome-power-manager-2.13.90-1 ----------------------------- * Wed Feb 15 2006 Matthias Clasen - 2.13.90-1 - Update to 2.13.90 - Require dbus-x11 (#176656) gnome-utils-1:2.13.92-4 ----------------------- * Mon Feb 20 2006 Matthias Clasen - 2.13.92-4 - Fix a crash in gnome-system-log when closing logs gnucash-1.8.12-3 ---------------- * Mon Feb 20 2006 Bill Nottingham - 1.8.12-3 - rebuild against g-wrap-1.9.6 gnupg-1.4.2.1-4 --------------- * Mon Feb 20 2006 Nalin Dahyabhai - 1.4.2.1-4 - rebuild * Mon Feb 20 2006 Nalin Dahyabhai - 1.4.2.1-3 - add patch from David Shaw to fix error reading keyrings created with older versions of GnuPG (Enrico Scholz, #182163) isdn4k-utils-3.2-39 ------------------- * Fri Feb 17 2006 Than Ngo 3.2-39 - fix rpm file conflict #181854 kernel-2.6.15-1.1969_FC5 ------------------------ * Sat Feb 18 2006 Dave Jones - Reenable EMI26 driver. (#181813) - Fix counting of hotplug cpu's in x86 microcode driver - Fix syscall auditting doing allocations whilst atomic. - Disable setting of security attributes on new inodes when no policy is loaded. (#180296) * Fri Feb 17 2006 Dave Jones - 2.6.16rc4 - 2.6.16rc3-git8 & git9 * Thu Feb 16 2006 John W. Linville - stop adding duplicate MODULE_VERSION line to tg3 lftp-3.4.2-4 ------------ * Thu Feb 16 2006 Jason Vas Dias - 3.4.2-4 - Apply upstream fix for bug 181694. * Wed Feb 15 2006 Jason Vas Dias - 3.4.2-2 - fix bug 181694: segfault on redirection to non-existent location mesa-6.4.2-3 ------------ * Sun Feb 19 2006 Ray Strode 6.4.2-3 - enable texture-from-drawable patch - add glut-devel dependency metacity-2.13.89.0.2006.02.17-2 ------------------------------- * Sun Feb 19 2006 Ray Strode - 2.13.89.0.2006.02.17-2 - disable compositor on s390 s390x and ppc64 * Fri Feb 17 2006 Ray Strode - 2.13.89.0.2006.02.17-1 - Update to latest cvs snapshot to give meaningful failure error messages - Don't remove build root in install, because it triggers a rebuild of metacity * Thu Feb 16 2006 Ray Strode - 2.13.89.0.2006.02.16-1 - Update to cvs snapshot to add the ability to runtime enable compositor - change %makeinstall to make install DESTDIR=.. pango-1.11.5-2 -------------- * Fri Feb 17 2006 Matthias Clasen - 1.11.5-2 - Fix a crash in pango_split - Hide some private API perl-HTML-Parser-3.50-1 ----------------------- * Mon Feb 20 2006 Jason Vas Dias - 3.50-1 - upgrade to 3.50 redhat-artwork-0.239-1 ---------------------- * Fri Feb 17 2006 Matthias Clasen - 0.239-1 - Make the login screen adapt to label width scim-1.4.4-5 ------------ * Mon Feb 20 2006 Warren Togami - 1.4.4-5 - Add epoch to iiimf Obsoletes so it actually removes it (#173071) NOTE: The goal of these Obsoletes are for the official supported upgrade path to work smoothly. If users want to use iiimf, they are free to do so but their package must be compatible. selinux-policy-2.2.17-2 ----------------------- * Mon Feb 20 2006 Dan Walsh 2.2.17-2 - Update to upstream - Fix semoudle polcy * Thu Feb 16 2006 Dan Walsh 2.2.16-1 - Update to upstream - fix sysconfig/selinux link vte-0.11.18-1.fc5.2 ------------------- * Fri Feb 17 2006 Matthias Clasen 0.11.18-2 - Change Shift-Insert back to insert PRIMARY xorg-x11-proto-devel-7.0-4 -------------------------- * Sun Feb 19 2006 Ray Strode 7.0-4 - Add back part of glproto-texture-from-drawable patch that didn't get integrated for some reason * Thu Feb 16 2006 Mike A. Harris 7.0-3 - Update to glproto-1.4.4 - Drop glproto-texture-from-drawable patch, which is integrated now. * Fri Feb 10 2006 Jesse Keating 7.0-2.3 - bump again for double-long bug on ppc(64) Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15-5.FC5.4.i686 requires kernel = 0:2.6.15-1.1955_FC5 GFS-kernel - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5 GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5smp cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp gnbd-kernel - 2.6.15-5.FC5.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs vconfig - 1.9-1.1.ia64 requires libc.so.6 vconfig - 1.9-1.1.ia64 requires libc.so.6(GLIBC_2.0) Broken deps for ppc64 ---------------------------------------------------------- emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi vconfig - 1.9-1.1.ppc64 requires libc.so.6 vconfig - 1.9-1.1.ppc64 requires libc.so.6(GLIBC_2.0) Broken deps for s390 ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 Broken deps for s390x ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 From che666 at gmail.com Tue Feb 21 10:18:10 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Tue, 21 Feb 2006 11:18:10 +0100 Subject: OpenLDAP config update from RPM In-Reply-To: <1140424030.29378.4.camel@xpc.home.erwinrol.com> References: <1140129969.17385.246.camel@xpc.home.erwinrol.com> <1140187381.15963.2.camel@dhollis-lnx.sunera.com> <1140221788.17385.302.camel@xpc.home.erwinrol.com> <1140406535.5240.5.camel@currant.watzmann.net> <1140424030.29378.4.camel@xpc.home.erwinrol.com> Message-ID: 2006/2/20, Erwin Rol : > On Sun, 2006-02-19 at 19:35 -0800, David Lutterkort wrote: > > On Sat, 2006-02-18 at 01:16 +0100, Erwin Rol wrote: > > > That is what i did now, because i saw some other RPM's that used "patch" > > > to change system config files like postgres, openldap and httpd/tomcat > > ^^^^^^^^ > > > > Do you remember which packages dealt with postgres that way ? > > Those "other RPM's" were some Open Xchange RPM's I found on the net, > nothing official. > > -Erwin > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > actually with a small python script the "include" bit can be added and removed from the openldap config in a rather clean way so open xchange can work out of the box if you do it with %post* if theres no security problem etc with it why not add it? Sure its always "not that nice" to do stuff like that but in the end i see it as somewhat of a design flaw of the server package. a /etc/ldap.config.d/ or something similar would fix it properly in my eyes. regards, rudolf kastl From veillard at redhat.com Tue Feb 21 10:31:33 2006 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 21 Feb 2006 05:31:33 -0500 Subject: Xen issues - Was Xen network performance problem during kickstart. In-Reply-To: <1140508134.2384.126.camel@dragon.sys.intra> References: <1139987549.21111.68.camel@dragon.sys.intra> <1140052865.2302.64.camel@host-81-191-138-132.bluecom.no> <1140060379.21111.145.camel@dragon.sys.intra> <1140078535.4651.84.camel@dragon.sys.intra> <1140157902.3229.32.camel@dragon.sys.intra> <1140442863.3357.4.camel@orbit.scot.redhat.com> <1140451864.2384.81.camel@dragon.sys.intra> <1140508134.2384.126.camel@dragon.sys.intra> Message-ID: <20060221103132.GA9506@redhat.com> On Tue, Feb 21, 2006 at 04:48:54PM +0900, Naoki wrote: > > On the guest that I was running the transfer tests on this popped up > sometime afterwards. > > [root at localhost ~]# BUG: soft lockup detected on CPU#0! Based on Rik findings, if Dom0 consume CPU too agressively it can starve the DomU leading to this. It was suggested on the Xen devel list to run xm sched-sedf 0 0 0 1 1 to avoid the risk of starvation, until the default behaviour is changed to avoid this. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 21 11:06:39 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 21 Feb 2006 12:06:39 +0100 Subject: MySQL support missing in dovecot on x86_64 Message-ID: <20060221120639.78d19c62@python2> Hi, I've opened this report for RHEL4, but it's still valid for current FC : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182240 Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.15-1.1831_FC4 Load : 0.51 0.65 0.56 From rc040203 at freenet.de Tue Feb 21 12:51:59 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 21 Feb 2006 13:51:59 +0100 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <20060220164029.GA28228@devserv.devel.redhat.com> References: <16330.217.33.199.77.1140444103.squirrel@mauro.ezplanet.net> <20060220145632.GD2861@free.fr> <1140448921.21764.589.camel@mccallum.corsepiu.local> <20060220153533.GB29559@devserv.devel.redhat.com> <1140451843.21764.593.camel@mccallum.corsepiu.local> <20060220164029.GA28228@devserv.devel.redhat.com> Message-ID: <1140526320.14289.44.camel@mccallum.corsepiu.local> On Mon, 2006-02-20 at 11:40 -0500, Alan Cox wrote: > On Mon, Feb 20, 2006 at 05:10:43PM +0100, Ralf Corsepius wrote: > > > OpenMotif is not free software by the FSF test. You can't for example use it > > > with proprietary Nvidia drivers loaded. > > > > Only if you consider Nvidia's drivers to be integral part of the kernel. > > I consider them to be optional add-ons/plug-ins. > > I asked the open group long ago and the email reply I got was to the contrary Well, as the same would apply to ATI drivers, this would render OpenMotif de-facto free of any practical applicability. Also, * this doesn't match to their FAQ, where they claim to be wanting to aim at OSI compatibility. * closed source kernel drivers are in existence for quite some time, some are even being shipped by some Linux vendors, but I've never heard the OpenGroup trying to enforce the interpretation of their license you outline. Furthermore, IIRC, their license originally was intended to prevent using OpenMotif on "traditional *nixes" which ship with closed source implementations/derivatives of the old OSF-Motif. What concerns me much more on Fedora and Linux is OpenMotif's license not to being [L]GPL compatible. Ralf From che666 at gmail.com Tue Feb 21 13:23:09 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Tue, 21 Feb 2006 14:23:09 +0100 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: References: <49412.217.33.199.77.1140434038.squirrel@mauro.ezplanet.net> <1140435192.2979.45.camel@laptopd505.fenrus.org> <1140435779.29378.6.camel@xpc.home.erwinrol.com> <19078.217.33.199.77.1140436567.squirrel@mauro.ezplanet.net> <43F9C4F6.5030700@mharris.ca> <65095.217.33.199.77.1140443222.squirrel@mauro.ezplanet.net> <43F9C905.60402@fedoraproject.org> Message-ID: 2006/2/20, Benjy Grogan : > > > On 2/20/06, Rahul Sundaram wrote: > > Mauro Mozzarelli wrote: > > > > >>Kaimano wrote: > > >> > > > > >The concerns are about spending more time for planning and design in > order > > >to move towards a really open platform, otherwise the risk is to end up > > >with an open source so complicated to maintain that it would not make any > > >difference if it was proprietary and secret. > > > > > > > > How are you willing to help? > > I think this is the most interesting thing about open source. How do people > get involved in open source projects? It would be great to hear some of the > stories. I'm sure there are many more people out there who would like to > help and have the technical wherewithal to help but simply can't find a way > to get started. > > I'd like to hear about people who in the last two or three years got > involved in a certain project. I realize there are those who have been > around for ten or more years and actually started some of the projects. But > how are newcomers helping out in software development? This is a fedora unspecific list of things you can do to get there: 1. getting involved as developer: grab cvs of . fix up compile errors/compiler warnings... diff -u oldfile newfile > patchfile and then email the patch to the upstream author ;)) -> you are involved ;) 2. getting involved as non programmer: 2.1 translating applications -> look for localisation projects etc or just grab an app and translate it. tools are available. 2.2 documentation -> write good documentation covering certain topics of interest 2.3 artwork -> make nice artwork (themes, 3d models, textures etc) for already existing projects (app themes, games, etc) and submit it upstream or publish it yourself while licensing it under a free license ;) 2.4 sound -> create desktop sounds, startup sounds, notifications sounds, oss game sfx/music) and send it upstream or publish it yourself under a free license. 2.5 submit good feedback to upstream developers (note: sounds easier than it is) regards, rudolf kastl ----> to get involved all you have to do is actually _do_ something. > > Benji > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From pertusus at free.fr Tue Feb 21 13:54:54 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 21 Feb 2006 14:54:54 +0100 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <1140526320.14289.44.camel@mccallum.corsepiu.local> References: <16330.217.33.199.77.1140444103.squirrel@mauro.ezplanet.net> <20060220145632.GD2861@free.fr> <1140448921.21764.589.camel@mccallum.corsepiu.local> <20060220153533.GB29559@devserv.devel.redhat.com> <1140451843.21764.593.camel@mccallum.corsepiu.local> <20060220164029.GA28228@devserv.devel.redhat.com> <1140526320.14289.44.camel@mccallum.corsepiu.local> Message-ID: <20060221135454.GH2729@free.fr> > * this doesn't match to their FAQ, where they claim to be wanting to aim > at OSI compatibility. Yep, but in the previous question they explain that the licence isn't allready OSI compatible: QUESTION: Does the Open Group Public License for Motif meet the Open Source Guidelines? ANSWER: No. The Open Group Public License for Motif grants rights only to use the software on or with operating systems that are themselves Open Source programs. In restricting the applicability of the license to Open Source platforms this does not meet term 8 of the Open Software Definition (http://www.opensource.org/osd.html). > What concerns me much more on Fedora and Linux is OpenMotif's license > not to being [L]GPL compatible. That shouldn't be an issue, if openmotif has a [L]GPL incompatible licence but is shipped as shared libs. -- Pat From alan at redhat.com Tue Feb 21 14:19:44 2006 From: alan at redhat.com (Alan Cox) Date: Tue, 21 Feb 2006 09:19:44 -0500 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <1140526320.14289.44.camel@mccallum.corsepiu.local> References: <16330.217.33.199.77.1140444103.squirrel@mauro.ezplanet.net> <20060220145632.GD2861@free.fr> <1140448921.21764.589.camel@mccallum.corsepiu.local> <20060220153533.GB29559@devserv.devel.redhat.com> <1140451843.21764.593.camel@mccallum.corsepiu.local> <20060220164029.GA28228@devserv.devel.redhat.com> <1140526320.14289.44.camel@mccallum.corsepiu.local> Message-ID: <20060221141944.GA25869@devserv.devel.redhat.com> On Tue, Feb 21, 2006 at 01:51:59PM +0100, Ralf Corsepius wrote: > Well, as the same would apply to ATI drivers, this would render > OpenMotif de-facto free of any practical applicability. It is anyway, does anyone use motif ? as far as I can see its a good extras candidate > Furthermore, IIRC, their license originally was intended to prevent > using OpenMotif on "traditional *nixes" which ship with closed source > implementations/derivatives of the old OSF-Motif. I'm just reporting what I was told at the time. From jspaleta at gmail.com Tue Feb 21 14:27:53 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 21 Feb 2006 09:27:53 -0500 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <20060221141944.GA25869@devserv.devel.redhat.com> References: <16330.217.33.199.77.1140444103.squirrel@mauro.ezplanet.net> <20060220145632.GD2861@free.fr> <1140448921.21764.589.camel@mccallum.corsepiu.local> <20060220153533.GB29559@devserv.devel.redhat.com> <1140451843.21764.593.camel@mccallum.corsepiu.local> <20060220164029.GA28228@devserv.devel.redhat.com> <1140526320.14289.44.camel@mccallum.corsepiu.local> <20060221141944.GA25869@devserv.devel.redhat.com> Message-ID: <604aa7910602210627y4df11d30o54e9974d54c6346b@mail.gmail.com> On 2/21/06, Alan Cox wrote: > It is anyway, does anyone use motif ? as far as I can see its a good > extras candidate tetex-xdvi and xpdf I can not support dropping tetex-xdvi until the fedora packages of evince turn on the dvi support, which is still marked as experiemental. I don't produce any dvi anymore thanks to pdflatex.. but fedora core still ships a number of dvi files as part of its own packages and I think fedora needs to continue to ship a application which can view those files. Until the fedora maintainers for evince turns on the dvi support.. tetex-xdvi really needs to stay..which means unfortunately that openmotif needs to stay. Feel free to help me convince the evince maintainer to turn on the dvi support in the Fedora evince package. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173514 -jef From pertusus at free.fr Tue Feb 21 14:33:41 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 21 Feb 2006 15:33:41 +0100 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <20060221141944.GA25869@devserv.devel.redhat.com> References: <16330.217.33.199.77.1140444103.squirrel@mauro.ezplanet.net> <20060220145632.GD2861@free.fr> <1140448921.21764.589.camel@mccallum.corsepiu.local> <20060220153533.GB29559@devserv.devel.redhat.com> <1140451843.21764.593.camel@mccallum.corsepiu.local> <20060220164029.GA28228@devserv.devel.redhat.com> <1140526320.14289.44.camel@mccallum.corsepiu.local> <20060221141944.GA25869@devserv.devel.redhat.com> Message-ID: <20060221143341.GI2729@free.fr> On Tue, Feb 21, 2006 at 09:19:44AM -0500, Alan Cox wrote: > On Tue, Feb 21, 2006 at 01:51:59PM +0100, Ralf Corsepius wrote: > > Well, as the same would apply to ATI drivers, this would render > > OpenMotif de-facto free of any practical applicability. > > It is anyway, does anyone use motif ? as far as I can see its a good > extras candidate It isn't a good extra candidate, because of its licence... Or am I missing something? If it turns out that there is no licence issue, I do agree that it would better be in extras than in core, once it doesn't have any dependencies in core anymore. -- Pat From mmkernel at ezplanet.net Tue Feb 21 14:59:38 2006 From: mmkernel at ezplanet.net (Mauro Mozzarelli) Date: Tue, 21 Feb 2006 14:59:38 -0000 (GMT) Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: References: <16330.217.33.199.77.1140444103.squirrel@mauro.ezplanet.net> Message-ID: <65023.217.33.199.77.1140533978.squirrel@mauro.ezplanet.net> > I think the first step would be to describe the problem in > more concrete terms. Actual problems that could be addressed, > instead of vague generalizations that could apply to anything. > > Having concrete goals would be good, too. > > If the goals and the problem description are interesting and > deemed realistic, then I'm sure developers would join your > effort. > Here is an outline (anyone is welcome to reviewing it): Main goal: to build a portable OS platform that allows for application inter-operability and flexibility in the interchange of core indentifiable components Principles: 1) a component can be replaced without impact on other components 2) components' interoperability is defined by a contract (API) that although can be extended, it cannot change the rules established in previous baselines. Main tasks: 1) to identify the core components 2) to identify independently repleceable groups of packages 4) to isolate the core components in replaceable units 5) to influence the development of critical software libraries and components as services with a defined API that supports backwards compatibility This project requires the cooperation of the following roles: 1) OS architects 2) Packagers 3) package designers/developers TASK 1: to identify core components Key roles: all This is a task that could be carried out by everyone through a proposal/review process. The scope is to identify those components that we would like to be able to replace (either new releases of the same component or a different competing component) without impacting on the integrity of the rest of the system. Core components can be product suites, like desktop managers, vital libraries like "cairo" or applications like openoffice. An example could be: Xorg KDE GNOME cairo Openoffice Firefox Mozilla Apache Java JVM/JDK gcc glibc TASK 2: to identify independently repleceable groups of packages key roles: packagers Translating in real terms: At the base of the success of this project is the cooperation between a number of different roles that at present might not be happening. An example could be the packager that takes care of building an "rpm" but is not involved in the development and design of the packaged component. The packager in this case would see a shift of his responsibilities from passive package maker to architect and influencer, feeding specific OS requirements to the components' designers. Having that as our goal, we can start with this task that could be carried out by the packager(s) alone. The aim is to place the core components identified in TASK 1 in packages groups. Definition of package group: those packages that are dependent on each other at release level and the replacement of one of them has an impact on(requires the replacement of) one of more of the other packages in the group. We can expect that at present we will be able to identify several intersecting (overlapping) package groups. The completion of this task will add the following value: 1) to achieve a better understanding of the extent of the problem 2) to allow for an initial identification of packages in groups that if replaced at once do not have an impact on the rest of the system, thus enabling their replacement with newer or different groups. TASK 3 - to isolate the core components in replaceable units Key roles: OS architects, packagers, package analysts/developers This is the task where we make significant changes to happen, and really requires the buy in of all of the key roles. If we are serious about this project, I propose to get a wiki page/section, so that we can build and review this and more of the documentation that we will require, keeping this mailing list as the communication channel. Please let me have your comments as soon as possible. -- Mauro Mozzarelli eMail: mauro at ezplanet.net From katzj at redhat.com Tue Feb 21 15:31:38 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 21 Feb 2006 10:31:38 -0500 Subject: FC5T3 on x86_64 In-Reply-To: <20060221164715.tpn9aadoisco88wc@imp.rexursive.com> References: <20060221164715.tpn9aadoisco88wc@imp.rexursive.com> Message-ID: <1140535898.12414.2.camel@orodruin.boston.redhat.com> On Tue, 2006-02-21 at 16:47 +1100, Bojan Smojver wrote: > I'm trying to upgrade an FC4 box (x86_64) to FC5T3, but I'm getting an > error just after "Preparing transaction from the installation media". > Basically, the message is something like "We should really show you the > debug info here, but we'll just fail instead." On VT3 I can see that > there are file conflicts between packages from FC4 and FC5T3, namely > for xpdf, xorg-x11-devel, python-devel, vim-common and e2fsprogs. Not > sure if those are harmless or if they are actually causing the install > to stop. Yes, the conflicts will currently cause things to stop. Could you file the list so that we can add them to the handler for these. Jeremy From pjones at redhat.com Tue Feb 21 15:36:21 2006 From: pjones at redhat.com (Peter Jones) Date: Tue, 21 Feb 2006 10:36:21 -0500 Subject: FC5 test3 -- dmraid broken? In-Reply-To: <1140499892.3430.13.camel@mentorng.gurulabs.com> References: <1140499892.3430.13.camel@mentorng.gurulabs.com> Message-ID: <1140536181.20618.2.camel@localhost.localdomain> On Mon, 2006-02-20 at 22:31 -0700, Dax Kelson wrote: > mkdmnod > mkblkdevs > rmparts sda > rmparts sdb > dm create nvidia_hcddcidd 0 586114702 mirror core 2 64 nosync 2 8:16 0 8:0 0 > dm partadd nvidia_hcddcidd > echo Scanning logical volumes > lvm vgscan --ignorelockingfailure > echo Activating logical volumes > lvm vgchange -ay --ignorelockingfailure VolGroup00 > resume /dev/VolGroup00/LogVol01 Ok, so this does all look fine -- can you add some sleeps in here and see if you can copy down exactly what these output, and see which one actually fails? If that fails we can build you an initrd by hand that has tools in it... -- Peter From arjan at fenrus.demon.nl Tue Feb 21 15:38:57 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Tue, 21 Feb 2006 16:38:57 +0100 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <1140526320.14289.44.camel@mccallum.corsepiu.local> References: <16330.217.33.199.77.1140444103.squirrel@mauro.ezplanet.net> <20060220145632.GD2861@free.fr> <1140448921.21764.589.camel@mccallum.corsepiu.local> <20060220153533.GB29559@devserv.devel.redhat.com> <1140451843.21764.593.camel@mccallum.corsepiu.local> <20060220164029.GA28228@devserv.devel.redhat.com> <1140526320.14289.44.camel@mccallum.corsepiu.local> Message-ID: <1140536338.3082.31.camel@laptopd505.fenrus.org> On Tue, 2006-02-21 at 13:51 +0100, Ralf Corsepius wrote: > On Mon, 2006-02-20 at 11:40 -0500, Alan Cox wrote: > > On Mon, Feb 20, 2006 at 05:10:43PM +0100, Ralf Corsepius wrote: > > > > OpenMotif is not free software by the FSF test. You can't for example use it > > > > with proprietary Nvidia drivers loaded. > > > > > > Only if you consider Nvidia's drivers to be integral part of the kernel. > > > I consider them to be optional add-ons/plug-ins. > > > > I asked the open group long ago and the email reply I got was to the contrary > Well, as the same would apply to ATI drivers, this would render > OpenMotif de-facto free of any practical applicability. > > Also, > * this doesn't match to their FAQ, where they claim to be wanting to aim > at OSI compatibility. > * closed source kernel drivers are in existence for quite some time, > some are even being shipped by some Linux vendors, actually basically all sort-of-big linux vendors stopped shipping them for "a variety of reasons". From rc040203 at freenet.de Tue Feb 21 15:42:37 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 21 Feb 2006 16:42:37 +0100 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <20060221135454.GH2729@free.fr> References: <16330.217.33.199.77.1140444103.squirrel@mauro.ezplanet.net> <20060220145632.GD2861@free.fr> <1140448921.21764.589.camel@mccallum.corsepiu.local> <20060220153533.GB29559@devserv.devel.redhat.com> <1140451843.21764.593.camel@mccallum.corsepiu.local> <20060220164029.GA28228@devserv.devel.redhat.com> <1140526320.14289.44.camel@mccallum.corsepiu.local> <20060221135454.GH2729@free.fr> Message-ID: <1140536557.14289.76.camel@mccallum.corsepiu.local> On Tue, 2006-02-21 at 14:54 +0100, Patrice Dumas wrote: > > * this doesn't match to their FAQ, where they claim to be wanting to aim > > at OSI compatibility. > > Yep, but in the previous question they explain that the licence isn't > allready OSI compatible: They clearly expressed their intention, and thereby significantly weaken their written license. In front of a German they would be facing very difficult times because of this. > > What concerns me much more on Fedora and Linux is OpenMotif's license > > not to being [L]GPL compatible. > > That shouldn't be an issue, if openmotif has a [L]GPL incompatible licence > but is shipped as shared libs. The GPL doesn't allow this, the LGPL does. Ralf From dax at gurulabs.com Tue Feb 21 15:43:46 2006 From: dax at gurulabs.com (Dax Kelson) Date: Tue, 21 Feb 2006 08:43:46 -0700 Subject: FC5 test3 -- dmraid broken? In-Reply-To: <1140536181.20618.2.camel@localhost.localdomain> References: <1140499892.3430.13.camel@mentorng.gurulabs.com> <1140536181.20618.2.camel@localhost.localdomain> Message-ID: <1140536626.3472.1.camel@mentorng.gurulabs.com> On Tue, 2006-02-21 at 10:36 -0500, Peter Jones wrote: > On Mon, 2006-02-20 at 22:31 -0700, Dax Kelson wrote: > > > mkdmnod > > mkblkdevs > > rmparts sda > > rmparts sdb > > dm create nvidia_hcddcidd 0 586114702 mirror core 2 64 nosync 2 8:16 0 8:0 0 > > dm partadd nvidia_hcddcidd > > echo Scanning logical volumes > > lvm vgscan --ignorelockingfailure > > echo Activating logical volumes > > lvm vgchange -ay --ignorelockingfailure VolGroup00 > > resume /dev/VolGroup00/LogVol01 > > Ok, so this does all look fine -- can you add some sleeps in here and > see if you can copy down exactly what these output, and see which one > actually fails? Sure. When I get home tonight I'll do it. Dax Kelson Guru Labs From pertusus at free.fr Tue Feb 21 16:02:00 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 21 Feb 2006 17:02:00 +0100 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <1140536557.14289.76.camel@mccallum.corsepiu.local> References: <16330.217.33.199.77.1140444103.squirrel@mauro.ezplanet.net> <20060220145632.GD2861@free.fr> <1140448921.21764.589.camel@mccallum.corsepiu.local> <20060220153533.GB29559@devserv.devel.redhat.com> <1140451843.21764.593.camel@mccallum.corsepiu.local> <20060220164029.GA28228@devserv.devel.redhat.com> <1140526320.14289.44.camel@mccallum.corsepiu.local> <20060221135454.GH2729@free.fr> <1140536557.14289.76.camel@mccallum.corsepiu.local> Message-ID: <20060221160200.GJ2729@free.fr> > > That shouldn't be an issue, if openmotif has a [L]GPL incompatible licence > > but is shipped as shared libs. > The GPL doesn't allow this, the LGPL does. What I did understand is that you can dynamically link a GPL code with a GPL incompatible code, as long as it is the GPL app which is a derived work of the library and not the reverse. So, for example, you can link a GPL app against a proprietary libc. So it should be possible to link GPL apps (or even libraries) against non GPL libraries. You can not bundle the GPL app and the proprietary lib together however. I think that bundling together is a matter of interpretation, but what I have understood, for example is that they cannot be in the same tarball nor in the same srpm, but they can be in different tarballs on a CD. -- Pat From jfrieben at freesurf.fr Tue Feb 21 15:07:04 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Tue, 21 Feb 2006 16:07:04 +0100 (CET) Subject: The future of Linux - architecture and package In-Reply-To: <20060221141944.GA25869@devserv.devel.redhat.com> References: <20060221141944.GA25869@devserv.devel.redhat.com> Message-ID: <29169.194.94.224.254.1140534424.squirrel@jose.freesurf.fr> > > It is anyway, does anyone use motif ? as far as I can see its a good > extras candidate > Not that quickly, there are still several applications of general importance in Fedora Core that use Open Motif: - ddd GUI for several command-line debuggers, - tetex-xdvi X viewer for DVI files, - xpdf PDF file viewer for the X Window System. "evince" is very slow and rendering is flaky, so even "xpdf" is not dispensable yet. For the first two items there is no alternative around the block, unless someone volunteers to port them to "GTK" in the short run. JF From mmkernel at ezplanet.net Tue Feb 21 16:21:07 2006 From: mmkernel at ezplanet.net (Mauro Mozzarelli) Date: Tue, 21 Feb 2006 16:21:07 -0000 (GMT) Subject: Licensing brainstorm Message-ID: <54284.217.33.199.77.1140538867.squirrel@mauro.ezplanet.net> [...] > > You can not bundle the GPL app and the proprietary lib together however. I think that bundling together is a matter of interpretation, but what I have understood, for example is that they cannot be in the same tarball nor in the same srpm, but they can be in different tarballs on a CD. > Guys, please could we use this new thread for licensing discussions? -- Mauro From alan at clueserver.org Tue Feb 21 16:28:36 2006 From: alan at clueserver.org (alan) Date: Tue, 21 Feb 2006 08:28:36 -0800 (PST) Subject: Licensing brainstorm In-Reply-To: <54284.217.33.199.77.1140538867.squirrel@mauro.ezplanet.net> References: <54284.217.33.199.77.1140538867.squirrel@mauro.ezplanet.net> Message-ID: On Tue, 21 Feb 2006, Mauro Mozzarelli wrote: > > [...] >> >> You can not bundle the GPL app and the proprietary lib together however. > I think that bundling together is a matter of interpretation, but what I > have understood, for example is that they cannot be in the same tarball > nor in the same srpm, but they can be in different tarballs on a CD. >> > > Guys, please could we use this new thread for licensing discussions? Maybe we need a dependacy resolution system for licenses. Kind of like RPM, but more difficult. My suggested name would be "Wine Brick", if not for the Wine project. -- "George W. Bush -- Bringing back the Sixties one Nixon at a time." From sundaram at fedoraproject.org Tue Feb 21 16:30:44 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 21 Feb 2006 22:00:44 +0530 Subject: Licensing brainstorm In-Reply-To: <54284.217.33.199.77.1140538867.squirrel@mauro.ezplanet.net> References: <54284.217.33.199.77.1140538867.squirrel@mauro.ezplanet.net> Message-ID: <43FB4034.1070802@fedoraproject.org> Mauro Mozzarelli wrote: >[...] > > >>You can not bundle the GPL app and the proprietary lib together however. >> >> >I think that bundling together is a matter of interpretation, but what I >have understood, for example is that they cannot be in the same tarball >nor in the same srpm, but they can be in different tarballs on a CD. > > > >Guys, please could we use this new thread for licensing discussions? > > > Or better yet let the people who understand licenses aka lawyers throughly discuss this and let the developers handle actual development. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From seanlkml at sympatico.ca Tue Feb 21 15:58:59 2006 From: seanlkml at sympatico.ca (sean) Date: Tue, 21 Feb 2006 10:58:59 -0500 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <65023.217.33.199.77.1140533978.squirrel@mauro.ezplanet.net> References: <16330.217.33.199.77.1140444103.squirrel@mauro.ezplanet.net> <65023.217.33.199.77.1140533978.squirrel@mauro.ezplanet.net> Message-ID: On Tue, 21 Feb 2006 14:59:38 -0000 (GMT) "Mauro Mozzarelli" wrote: > Main goal: to build a portable OS platform that allows for application > inter-operability and flexibility in the interchange of core indentifiable > components > > Principles: > 1) a component can be replaced without impact on other components > 2) components' interoperability is defined by a contract (API) that > although can be extended, it cannot change the rules established in > previous baselines. > > Main tasks: > 1) to identify the core components > 2) to identify independently repleceable groups of packages > 4) to isolate the core components in replaceable units > 5) to influence the development of critical software libraries and > components as services with a defined API that supports backwards > compatibility Traditionally the way this is done is to extract common elements into a library and there are already a fair number of such libraries provided by Fedora. I guess you're saying that there should be more. Can you give one concrete example of code that should be pulled out of some application and put into a library? Once you've identified the first such oportunity you'll have a better chance of attracting people who are interested in the specific example you put forward. Sean From alan at redhat.com Tue Feb 21 16:55:34 2006 From: alan at redhat.com (Alan Cox) Date: Tue, 21 Feb 2006 11:55:34 -0500 Subject: The future of Linux - architecture and package In-Reply-To: <29169.194.94.224.254.1140534424.squirrel@jose.freesurf.fr> References: <20060221141944.GA25869@devserv.devel.redhat.com> <29169.194.94.224.254.1140534424.squirrel@jose.freesurf.fr> Message-ID: <20060221165534.GA10234@devserv.devel.redhat.com> On Tue, Feb 21, 2006 at 04:07:04PM +0100, Joachim Frieben wrote: > - ddd GUI for several command-line debuggers, Obscure and weird > - tetex-xdvi X viewer for DVI files, Tex belongs in extras, all of it > - xpdf PDF file viewer for the X Window System. Unusuably bad with most modern pdf files > "evince" is very slow and rendering is flaky, so even "xpdf" is not Agreed, but kpdf is snappy and except for some nasty printing bugs with rev 1.6 PDF works well From notting at redhat.com Tue Feb 21 17:00:26 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 21 Feb 2006 12:00:26 -0500 Subject: The future of Linux - architecture and package In-Reply-To: <20060221165534.GA10234@devserv.devel.redhat.com> References: <20060221141944.GA25869@devserv.devel.redhat.com> <29169.194.94.224.254.1140534424.squirrel@jose.freesurf.fr> <20060221165534.GA10234@devserv.devel.redhat.com> Message-ID: <20060221170026.GC3831@devserv.devel.redhat.com> Alan Cox (alan at redhat.com) said: > > - tetex-xdvi X viewer for DVI files, > > Tex belongs in extras, all of it This would blow up the entire build chain, though. :/ Bill From jspaleta at gmail.com Tue Feb 21 17:16:14 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 21 Feb 2006 12:16:14 -0500 Subject: The future of Linux - architecture and package In-Reply-To: <20060221165534.GA10234@devserv.devel.redhat.com> References: <20060221141944.GA25869@devserv.devel.redhat.com> <29169.194.94.224.254.1140534424.squirrel@jose.freesurf.fr> <20060221165534.GA10234@devserv.devel.redhat.com> Message-ID: <604aa7910602210916j34aff328v60b5585cc8019cd@mail.gmail.com> On 2/21/06, Alan Cox wrote: > Tex belongs in extras, all of it Please take a look at the other packages in Core which ship dvi files as part of their documentation. Its not so simple as to say all of tetex should be in extras. My concern is that other Core packages ship dvi files and currently the only viewer in Core that I am aware of with dvi file support is xdvi. I'd like to see that changed, so at least tetex-xdvi could be dropped and thus one step closer to dropping openmotif from Core. I'd actually agree to move tetex to extras with if it were possible.. but I don't think you can move it wholesale out of core because of buildrequires in other packages unless the selfhosting constraint on Core is lifted or you are prepared to drop all documentation which is generated via tetex as part of Core package build process for a number of packages. Given the current constraints with regard to packaging building, I very much doubt tetex will be moving to Core and I think such a discussion is a non-starter. But I would encourage you to take a look at the spec files in cvs which ask for latex as part of the build process and assess how difficult it would be to re-engineer Core packages so tetex could be moved to Core. -jef From ml2news at free.fr Tue Feb 21 17:29:55 2006 From: ml2news at free.fr (Mathieu Chouquet-Stringer) Date: 21 Feb 2006 18:29:55 +0100 Subject: The future of Linux - architecture and package In-Reply-To: <20060221165534.GA10234@devserv.devel.redhat.com> References: <20060221141944.GA25869@devserv.devel.redhat.com> <20060221165534.GA10234@devserv.devel.redhat.com> Message-ID: alan at redhat.com (Alan Cox) writes: > > - xpdf PDF file viewer for the X Window System. > > Unusuably bad with most modern pdf files Allow me to disagree here, I can forward you quite a bunch of recent pdfs evince can't read or just render the wrong way. For example I've got the manual for a Canon camera that has a big "COPY" sign in the background and that's the only thing evince renders (on all pages). -- Mathieu Chouquet-Stringer "Le disparu, si l'on v?n?re sa m?moire, est plus pr?sent et plus puissant que le vivant". -- Antoine de Saint-Exup?ry, Citadelle -- From sundaram at fedoraproject.org Tue Feb 21 17:34:48 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 21 Feb 2006 23:04:48 +0530 Subject: The future of Linux - architecture and package In-Reply-To: References: <20060221141944.GA25869@devserv.devel.redhat.com> <20060221165534.GA10234@devserv.devel.redhat.com> Message-ID: <43FB4F38.4000400@fedoraproject.org> Mathieu Chouquet-Stringer wrote: >alan at redhat.com (Alan Cox) writes: > > >>> - xpdf PDF file viewer for the X Window System. >>> >>> >>Unusuably bad with most modern pdf files >> >> > >Allow me to disagree here, I can forward you quite a bunch of recent pdfs >evince can't read or just render the wrong way. > >For example I've got the manual for a Canon camera that has a big "COPY" >sign in the background and that's the only thing evince renders (on all >pages). > > I think developers in evince list was looking for such test cases. http://mail.gnome.org/archives/evince-list/ -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From alan at redhat.com Tue Feb 21 17:43:39 2006 From: alan at redhat.com (Alan Cox) Date: Tue, 21 Feb 2006 12:43:39 -0500 Subject: The future of Linux - architecture and package In-Reply-To: References: <20060221141944.GA25869@devserv.devel.redhat.com> <20060221165534.GA10234@devserv.devel.redhat.com> Message-ID: <20060221174339.GB32093@devserv.devel.redhat.com> On Tue, Feb 21, 2006 at 06:29:55PM +0100, Mathieu Chouquet-Stringer wrote: > > > - xpdf PDF file viewer for the X Window System. > > Unusuably bad with most modern pdf files > > Allow me to disagree here, I can forward you quite a bunch of recent pdfs > evince can't read or just render the wrong way. I didn't say anything about evince, evince sucks too. I can give you pdfs that xpdf takes a week to render and kdpf renders correctly in 2 seconds. > For example I've got the manual for a Canon camera that has a big "COPY" > sign in the background and that's the only thing evince renders (on all > pages). Evince/xpdf/gimp and also print (but not view) in kpdf all mess up pdf files which contain images with transparent backgrounds for one, so no suprises. From sundaram at fedoraproject.org Tue Feb 21 17:46:15 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 21 Feb 2006 23:16:15 +0530 Subject: The future of Linux - architecture and package In-Reply-To: <20060221174339.GB32093@devserv.devel.redhat.com> References: <20060221141944.GA25869@devserv.devel.redhat.com> <20060221165534.GA10234@devserv.devel.redhat.com> <20060221174339.GB32093@devserv.devel.redhat.com> Message-ID: <43FB51E7.6040502@fedoraproject.org> Alan Cox wrote: >On Tue, Feb 21, 2006 at 06:29:55PM +0100, Mathieu Chouquet-Stringer wrote: > > >>>> - xpdf PDF file viewer for the X Window System. >>>> >>>> >>>Unusuably bad with most modern pdf files >>> >>> >>Allow me to disagree here, I can forward you quite a bunch of recent pdfs >>evince can't read or just render the wrong way. >> >> > >I didn't say anything about evince, evince sucks too. I can give you pdfs >that xpdf takes a week to render and kdpf renders correctly in 2 seconds. > > > >>For example I've got the manual for a Canon camera that has a big "COPY" >>sign in the background and that's the only thing evince renders (on all >>pages). >> >> > >Evince/xpdf/gimp and also print (but not view) in kpdf all mess up pdf files >which contain images with transparent backgrounds for one, so no suprises. > > Curious how KPDF works on files better when Evince doesnt where both of them use poppler as the underlying library. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From dennis at ausil.us Tue Feb 21 17:46:36 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 21 Feb 2006 11:46:36 -0600 Subject: The future of Linux - architecture and package In-Reply-To: <20060221165534.GA10234@devserv.devel.redhat.com> References: <20060221141944.GA25869@devserv.devel.redhat.com> <29169.194.94.224.254.1140534424.squirrel@jose.freesurf.fr> <20060221165534.GA10234@devserv.devel.redhat.com> Message-ID: <200602211146.37056.dennis@ausil.us> On Tuesday 21 February 2006 10:55, Alan Cox wrote: > Agreed, but kpdf is snappy and except for some nasty printing bugs with > rev 1.6 PDF works well except at the moment kpdf is not provided in kdegraphics rpm -q --changelog kdegraphics * Fri Feb 10 2006 Jesse Keating - 7:3.5.1-2.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Than Ngo 7:3.5.1-2 - apply patch to fix buffer overflow in kpdf, CVE-2006-0301 (#179425) - apply patch to fix gcc warning (#169189) doesnt show its removal but i guess that the patch is bad -- Regards Dennis Gilmore, RHCE Proud Australian From ml2news at free.fr Tue Feb 21 17:50:32 2006 From: ml2news at free.fr (Mathieu Chouquet-Stringer) Date: 21 Feb 2006 18:50:32 +0100 Subject: The future of Linux - architecture and package In-Reply-To: <20060221174339.GB32093@devserv.devel.redhat.com> References: <20060221141944.GA25869@devserv.devel.redhat.com> <20060221165534.GA10234@devserv.devel.redhat.com> <20060221174339.GB32093@devserv.devel.redhat.com> Message-ID: alan at redhat.com (Alan Cox) writes: > I didn't say anything about evince, evince sucks too. I can give you pdfs > that xpdf takes a week to render and kdpf renders correctly in 2 seconds. My bad I read your comment as "xpdf sucks more than evince", let's get rid of it. > Evince/xpdf/gimp and also print (but not view) in kpdf all mess up pdf files > which contain images with transparent backgrounds for one, so no suprises. Speaking of which, I can't seem to find kpdf on FC5T3, is it me or? -- Mathieu Chouquet-Stringer "Le disparu, si l'on v?n?re sa m?moire, est plus pr?sent et plus puissant que le vivant". -- Antoine de Saint-Exup?ry, Citadelle -- From nicolas.mailhot at laposte.net Tue Feb 21 18:11:11 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 21 Feb 2006 19:11:11 +0100 Subject: The future of Linux - architecture and package In-Reply-To: References: <20060221141944.GA25869@devserv.devel.redhat.com> <20060221165534.GA10234@devserv.devel.redhat.com> Message-ID: <1140545472.12119.1.camel@rousalka.dyndns.org> Le mardi 21 f?vrier 2006 ? 18:29 +0100, Mathieu Chouquet-Stringer a ?crit : > alan at redhat.com (Alan Cox) writes: > > > - xpdf PDF file viewer for the X Window System. > > > > Unusuably bad with most modern pdf files > > Allow me to disagree here, I can forward you quite a bunch of recent pdfs > evince can't read or just render the wrong way. Did you sent them to the evince people ? I hit quite a few problem pdf when evince was first released. After reporting them, everything was quickly fixed. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From alan at redhat.com Tue Feb 21 18:20:37 2006 From: alan at redhat.com (Alan Cox) Date: Tue, 21 Feb 2006 13:20:37 -0500 Subject: The future of Linux - architecture and package In-Reply-To: <1140545472.12119.1.camel@rousalka.dyndns.org> References: <20060221141944.GA25869@devserv.devel.redhat.com> <20060221165534.GA10234@devserv.devel.redhat.com> <1140545472.12119.1.camel@rousalka.dyndns.org> Message-ID: <20060221182037.GA17897@devserv.devel.redhat.com> On Tue, Feb 21, 2006 at 07:11:11PM +0100, Nicolas Mailhot wrote: > > Allow me to disagree here, I can forward you quite a bunch of recent pdfs > > evince can't read or just render the wrong way. > > Did you sent them to the evince people ? I think our lawyers would be cross if I did as they are copyrighted material. > I hit quite a few problem pdf when evince was first released. After > reporting them, everything was quickly fixed. www.scalescenes.com freebie building pdf is a good test (shows up the kpdf print wrong/view right bug and wont load into gimp) From laroche at redhat.com Tue Feb 21 18:20:58 2006 From: laroche at redhat.com (Florian La Roche) Date: Tue, 21 Feb 2006 19:20:58 +0100 Subject: The future of Linux - architecture and package In-Reply-To: <200602211146.37056.dennis@ausil.us> References: <20060221141944.GA25869@devserv.devel.redhat.com> <29169.194.94.224.254.1140534424.squirrel@jose.freesurf.fr> <20060221165534.GA10234@devserv.devel.redhat.com> <200602211146.37056.dennis@ausil.us> Message-ID: <20060221182058.GA3588@dudweiler.stuttgart.redhat.com> On Tue, Feb 21, 2006 at 11:46:36AM -0600, Dennis Gilmore wrote: > On Tuesday 21 February 2006 10:55, Alan Cox wrote: > > > Agreed, but kpdf is snappy and except for some nasty printing bugs with > > rev 1.6 PDF works well > except at the moment kpdf is not provided in kdegraphics > > rpm -q --changelog kdegraphics > * Fri Feb 10 2006 Jesse Keating - 7:3.5.1-2.1 > - bump again for double-long bug on ppc(64) > > * Tue Feb 07 2006 Than Ngo 7:3.5.1-2 > - apply patch to fix buffer overflow in kpdf, CVE-2006-0301 (#179425) > - apply patch to fix gcc warning (#169189) > > > doesnt show its removal but i guess that the patch is bad Hello Dennis, kpdf will be back, this is indeed a bad patch. regards, Florian La Roche From fedora-devel-list at cygnusx-1.org Tue Feb 21 18:31:04 2006 From: fedora-devel-list at cygnusx-1.org (Nathan Grennan) Date: Tue, 21 Feb 2006 10:31:04 -0800 Subject: rlocate vs. mlocate Message-ID: <43FB5C68.8070205@cygnusx-1.org> I have seen locate be replace by slocate, which has now been replace with mlocate. mlocate seems nice and all, but why aren't we moving to rlocate. Sometime in the last few months I got the impression that mlocate would do what rlocate does. Recently I have been using mlocate and with the impression it was like rlocate I was very disappointed with the results. It seemed broken. Today I investigated the reality and found mlocate is just an incremental improvement on slocate, but still only runs daily. rlocate seems like the ultimate solution with it's use of inotify for real time results. Why isn't Fedora moving to rlocate? Hopefully it isn't a case of not invented here, since I notice the mlocate author is a Red Hat employee. From bojan at rexursive.com Tue Feb 21 18:52:32 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 22 Feb 2006 05:52:32 +1100 Subject: FC5T3 on x86_64 In-Reply-To: <1140535898.12414.2.camel@orodruin.boston.redhat.com> References: <20060221164715.tpn9aadoisco88wc@imp.rexursive.com> <1140535898.12414.2.camel@orodruin.boston.redhat.com> Message-ID: <1140547953.2131.9.camel@coyote.rexursive.com> On Tue, 2006-02-21 at 10:31 -0500, Jeremy Katz wrote: > namely > > for xpdf, xorg-x11-devel, python-devel, vim-common and e2fsprogs. > > Yes, the conflicts will currently cause things to stop. Could you file > the list so that we can add them to the handler for these. I'm guessing you want to the actual conflicting files, not just the packages that are listed above. I'll have to run the upgrade again for that and write things down (of what I can see on the screen), because upgrade.log was empty (another bug?). So, just to understand this correctly, the upgrade code needs to know explicitly about every possible conflict in order to succeed, right? Surely, the code should be able to determine that files from new packages will actually replace files from the old packages and just go ahead (i.e. when the transaction is over, there won't be any real conflicts). Or is it more complicated than that? -- Bojan From dragoran at feuerpokemon.de Tue Feb 21 19:23:05 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 21 Feb 2006 20:23:05 +0100 Subject: FC5T3 on x86_64 In-Reply-To: <1140535898.12414.2.camel@orodruin.boston.redhat.com> References: <20060221164715.tpn9aadoisco88wc@imp.rexursive.com> <1140535898.12414.2.camel@orodruin.boston.redhat.com> Message-ID: <43FB6899.1010400@feuerpokemon.de> Jeremy Katz wrote: >On Tue, 2006-02-21 at 16:47 +1100, Bojan Smojver wrote: > > >>I'm trying to upgrade an FC4 box (x86_64) to FC5T3, but I'm getting an >>error just after "Preparing transaction from the installation media". >>Basically, the message is something like "We should really show you the >>debug info here, but we'll just fail instead." On VT3 I can see that >>there are file conflicts between packages from FC4 and FC5T3, namely >>for xpdf, xorg-x11-devel, python-devel, vim-common and e2fsprogs. Not >>sure if those are harmless or if they are actually causing the install >>to stop. >> >> > >Yes, the conflicts will currently cause things to stop. Could you file >the list so that we can add them to the handler for these. > >Jeremy > > > this behavier is *wrong* failing because a conflict on update without even tell the user about them isn't the right thing to do. what if sb has third party packages that conflicts with the new ones? the user should be asked if he/she wants to remove this package and proceed (can install them after the upgrade is done) or abort the install to solve the problem. From igorm5 at vip.hr Tue Feb 21 20:53:29 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Tue, 21 Feb 2006 21:53:29 +0100 Subject: Ralink rt2500, can't load module Message-ID: <43FB7DC9.8060307@vip.hr> I compiled beta3 and cvs drivers on FC5t3 and everything went ok, but the rt2500 module can't be loaded. On FC5t2's default kernel everything went ok (both, compiling and loading the rt2500 module). [root at localhost Module]# /sbin/modprobe rt2500 FATAL: Error inserting rt2500 (/lib/modules/2.6.15-1.1955_FC5/extra/rt2500.ko): Invalid argument Is it any way to load that module? No rt2500 support means no internet for me :-/ Thanks. Cheers! -- Igor Jagec From igorm5 at vip.hr Tue Feb 21 20:56:21 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Tue, 21 Feb 2006 21:56:21 +0100 Subject: Speaking about Pirut... Message-ID: <43FB7E75.6050506@vip.hr> Speaking about Pirut, it would be very nice if you make ncurces based version of Pirut for minimal instalation systems. And to add Wireless support to ncurces version of system-config-network as well. I know about NetworkManager but I use static IP address for my wireless network connection so I can forget about NM. Thanks. Cheers! -- Igor Jagec From arjan at fenrus.demon.nl Tue Feb 21 22:09:49 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Tue, 21 Feb 2006 23:09:49 +0100 Subject: Ralink rt2500, can't load module In-Reply-To: <43FB7DC9.8060307@vip.hr> References: <43FB7DC9.8060307@vip.hr> Message-ID: <1140559789.3082.37.camel@laptopd505.fenrus.org> On Tue, 2006-02-21 at 21:53 +0100, Igor Jagec wrote: > I compiled beta3 and cvs drivers on FC5t3 and everything went ok, but > the rt2500 module can't be loaded. On FC5t2's default kernel everything > went ok (both, compiling and loading the rt2500 module). > > [root at localhost Module]# /sbin/modprobe rt2500 > FATAL: Error inserting rt2500 > (/lib/modules/2.6.15-1.1955_FC5/extra/rt2500.ko): Invalid argument look in dmesg output for a more descriptive reason for the failure From nicolas.mailhot at laposte.net Tue Feb 21 21:47:24 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 21 Feb 2006 22:47:24 +0100 Subject: The future of Linux - architecture and package In-Reply-To: <20060221182037.GA17897@devserv.devel.redhat.com> References: <20060221141944.GA25869@devserv.devel.redhat.com> <20060221165534.GA10234@devserv.devel.redhat.com> <1140545472.12119.1.camel@rousalka.dyndns.org> <20060221182037.GA17897@devserv.devel.redhat.com> Message-ID: <1140558444.13224.2.camel@rousalka.dyndns.org> Le mardi 21 f?vrier 2006 ? 13:20 -0500, Alan Cox a ?crit : > On Tue, Feb 21, 2006 at 07:11:11PM +0100, Nicolas Mailhot wrote: > > > Allow me to disagree here, I can forward you quite a bunch of recent pdfs > > > evince can't read or just render the wrong way. > > > > Did you sent them to the evince people ? > > I think our lawyers would be cross if I did as they are copyrighted material. > > > I hit quite a few problem pdf when evince was first released. After > > reporting them, everything was quickly fixed. > > www.scalescenes.com freebie building pdf is a good test (shows up the kpdf > print wrong/view right bug and wont load into gimp) Waiting Shelter R001 seems to render and print fine with rawhide evince (apart from the usual "all the world is a Letter printer - let's f*-up A4 borders" Gnome print bug) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ericsbinaryworld at gmail.com Tue Feb 21 23:27:09 2006 From: ericsbinaryworld at gmail.com (Eric Mesa) Date: Tue, 21 Feb 2006 18:27:09 -0500 Subject: Non-free Extras? Message-ID: <43FBA1CD.4020908@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In order to pull in packagers like those maintaining Dries, Dag Weirs, freshrpms, and others, and in order to assure Fedora users that their packages would work instead of saying, "if you don't use official packages, you're on your own," has there been any conversation on taking an example from Debian and having a non-free repository? It would also free up the packagers who spend so much time duplicating each other's packages in order to ensure compatibility. I know there are issues with their ffmpeg and mp3 codecs, but could these issues be solved simply by designating their repositories as non-free? I think it would greatly enhance the Fedora experience, IMHO as a loyal FC user since Yarrow. - -- Eric Mesa ericsbinaryworld at gmail.com http://www.ericsbinaryworld.com Note: All emails from this address should have a GPG signature. If you have the proper setup you can use this to confirm my identity and that the email was not changed in transit. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFD+6HNPvU+8ApmWXIRApXBAJ9yZnV5o6OiE4ZHINorajzzaYIdzQCeKYx/ 8+z2CY7CAzRXf8FaJxn3sWs= =rLiE -----END PGP SIGNATURE----- From paul at all-the-johnsons.co.uk Tue Feb 21 23:52:04 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Tue, 21 Feb 2006 23:52:04 +0000 Subject: Non-free Extras? In-Reply-To: <43FBA1CD.4020908@gmail.com> References: <43FBA1CD.4020908@gmail.com> Message-ID: <1140565924.31940.17.camel@T7.Linux> Hi, > In order to pull in packagers like those maintaining Dries, Dag Weirs, > freshrpms, and others, and in order to assure Fedora users that their > packages would work instead of saying, "if you don't use official > packages, you're on your own," has there been any conversation on > taking an example from Debian and having a non-free repository? It > would also free up the packagers who spend so much time duplicating > each other's packages in order to ensure compatibility. I know there > are issues with their ffmpeg and mp3 codecs, but could these issues be > solved simply by designating their repositories as non-free? I think > it would greatly enhance the Fedora experience, IMHO as a loyal FC > user since Yarrow. Personally, I'd love to see everything under one roof or failing that, have freshrpms and livna have the equivalent of a rawhide build. TTFN Paul (RH user since um, cripes, when was it first released?) -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show From gmaxwell at gmail.com Tue Feb 21 23:55:49 2006 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Tue, 21 Feb 2006 18:55:49 -0500 Subject: Non-free Extras? In-Reply-To: <1140565924.31940.17.camel@T7.Linux> References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> Message-ID: On 2/21/06, Paul F. Johnson wrote: > Personally, I'd love to see everything under one roof or failing that, > have freshrpms and livna have the equivalent of a rawhide build. Most of the external archives are almost completely useless to those who wish to, or must, keep their system of unfree software because there is no way to inhibit the random stray dependency from sucking in a lot of non-free stuff. Before talking about unified repositories and such, that issue should be addressed. From hhoffman at ip-solutions.net Wed Feb 22 00:08:22 2006 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Tue, 21 Feb 2006 19:08:22 -0500 Subject: xenguest-install.py on FC5-t3 Message-ID: <43FBAB76.2040301@ip-solutions.net> Hi, I'm looking at the Quickstart under FC5 for Xen and running into trouble. I've created a disk image using dd to a file and am now stuck as to where I get the install media. Can anyone provide a pointer for what args I should be supplying this script? Below is what I tried. Thanks, Harry [root at n1-22-30 ~]# xenguest-install.py What is the name of your virtual machine? ldap How much RAM should be allocated (in megabytes)? 256 What would you like to use as the disk (path)? /srv/xen/ldap/ldap.xen Invalid source specified. Please specify an NFS, HTTP, or FTP install source What is the install location? http://download.fedora.redhat.com/pub/fedora/linux/core/4/i386/os/ http://download.fedora.redhat.com/pub/fedora/linux/core/4/i386/os/ Traceback (most recent call last): File "/usr/sbin/xenguest-install.py", line 365, in ? main() File "/usr/sbin/xenguest-install.py", line 356, in main start_paravirt_install(name, ram, disk, mac, src, options.extra) File "/usr/sbin/xenguest-install.py", line 232, in start_paravirt_install (kfn, ifn) = get_paravirt_install_image(src) File "/usr/sbin/xenguest-install.py", line 196, in get_paravirt_install_image kernel = grabber.urlopen("%s/images/xen/vmlinuz" %(src,)) File "/usr/lib/python2.4/site-packages/urlgrabber/grabber.py", line 444, in urlopen return default_grabber.urlopen(url, **kwargs) File "/usr/lib/python2.4/site-packages/urlgrabber/grabber.py", line 575, in urlopen return self._retry(opts, retryfunc, url) File "/usr/lib/python2.4/site-packages/urlgrabber/grabber.py", line 547, in _retry return apply(func, (opts,) + args, {}) File "/usr/lib/python2.4/site-packages/urlgrabber/grabber.py", line 574, in retryfunc return URLGrabberFileObject(url, filename=None, opts=opts) File "/usr/lib/python2.4/site-packages/urlgrabber/grabber.py", line 728, in __init__ self._do_open() File "/usr/lib/python2.4/site-packages/urlgrabber/grabber.py", line 820, in _do_open fo, hdr = self._make_request(req, opener) File "/usr/lib/python2.4/site-packages/urlgrabber/grabber.py", line 902, in _make_request raise URLGrabError(4, _('IOError: %s') % (e, )) urlgrabber.grabber.URLGrabError: [Errno 4] IOError: HTTP Error 404: Date: Wed, 22 Feb 2006 00:04:03 GMT Server: Apache Last-Modified: Tue, 21 Feb 2006 23:45:33 GMT Accept-Ranges: bytes Content-Length: 3542 Content-Type: text/html; charset=UTF-8 From ericsbinaryworld at gmail.com Wed Feb 22 00:14:59 2006 From: ericsbinaryworld at gmail.com (Eric Mesa) Date: Tue, 21 Feb 2006 19:14:59 -0500 Subject: Non-free Extras? In-Reply-To: References: <43FBA1CD.4020908@gmail.com> Message-ID: <43FBAD03.3000305@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 sean wrote: > On Tue, 21 Feb 2006 18:27:09 -0500 Eric Mesa > wrote: > >> Hash: SHA1 >> >> In order to pull in packagers like those maintaining Dries, Dag >> Weirs, freshrpms, and others, and in order to assure Fedora users >> that their packages would work instead of saying, "if you don't >> use official packages, you're on your own," has there been any >> conversation on taking an example from Debian and having a >> non-free repository? It would also free up the packagers who >> spend so much time duplicating each other's packages in order to >> ensure compatibility. I know there are issues with their ffmpeg >> and mp3 codecs, but could these issues be solved simply by >> designating their repositories as non-free? I think it would >> greatly enhance the Fedora experience, IMHO as a loyal FC user >> since Yarrow. >> > > Not speaking as an authority, but such notions are directly against > the stated goals of this project. The fact that there are some > people who want to also use non-free software doesn't (and > shouldn't) change the nature or goals of the project itself. Those > who want to do so should create a central repository themselves and > provide whatever guarantees they can muster. It's not likely to > ever be able to use Fedora branding though. > > Sean > I figured. I thought it was worth asking, just in case. - -- Eric Mesa ericsbinaryworld at gmail.com http://www.ericsbinaryworld.com Note: All emails from this address should have a GPG signature. If you have the proper setup you can use this to confirm my identity and that the email was not changed in transit. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFD+60CPvU+8ApmWXIRAq//AJ91nwuJJX5pbKg7IcKdlhNcq9MzxACfY7N5 xLFvCzeiQ/+hHi1RDcVufNs= =4Tax -----END PGP SIGNATURE----- From sundaram at fedoraproject.org Wed Feb 22 00:17:47 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 22 Feb 2006 05:47:47 +0530 Subject: xenguest-install.py on FC5-t3 In-Reply-To: <43FBAB76.2040301@ip-solutions.net> References: <43FBAB76.2040301@ip-solutions.net> Message-ID: <43FBADAB.2050706@fedoraproject.org> Harry Hoffman wrote: >Hi, > >I'm looking at the Quickstart under FC5 for Xen and running into trouble. > >I've created a disk image using dd to a file and am now stuck as to >where I get the install media. > >Can anyone provide a pointer for what args I should be supplying this >script? > >Below is what I tried. > >Thanks, >Harry > > >[root at n1-22-30 ~]# xenguest-install.py >What is the name of your virtual machine? ldap > How much RAM should be allocated (in megabytes)? 256 > What would you like to use as the disk (path)? /srv/xen/ldap/ldap.xen > Invalid source specified. Please specify an NFS, HTTP, or FTP install >source >What is the install location? >http://download.fedora.redhat.com/pub/fedora/linux/core/4/i386/os/ > http://download.fedora.redhat.com/pub/fedora/linux/core/4/i386/os/ >Traceback (most recent call last): > Try http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/ -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From mitr at volny.cz Wed Feb 22 00:24:04 2006 From: mitr at volny.cz (Miloslav Trmac) Date: Wed, 22 Feb 2006 01:24:04 +0100 Subject: rlocate vs. mlocate In-Reply-To: <43FB5C68.8070205@cygnusx-1.org> References: <43FB5C68.8070205@cygnusx-1.org> Message-ID: <43FBAF24.5000607@volny.cz> Hello, Nathan Grennan napsal(a): > Sometime in the last few months I got the impression that > mlocate would do what rlocate does. I have no idea why... > rlocate seems like the ultimate solution with it's use > of inotify for real time results. Note that rlocate actually doesn't use inotify. > Why isn't Fedora moving to rlocate? Hopefully it isn't a case of not > invented here, since I notice the mlocate author is a Red Hat employee. Some history: I decided to write mlocate as a "for fun" project at the time an audit-based locate replacement was proposed for the Summer of Code, in order to have something different for speed comparison. I did look at existing alternatives with minimal run-time overhead (the possible audit-based locate would have an always-running daemon); a kernel module and a daemon didn't fit my idea of minimal overhead, so I have ignored rlocate. I was ready to write off the development time of mlocate as a "personal fun project, not paid by Red Hat", if it wouldn't be a noticeable improvement. The decision happened basically like this: mitr> I'd like to replace slocate by mlocate for FC5 and beyond. mitr> [mlocate is a noticeable incremental improvement over slocate]. decision makers> OK, makes sense. It seems mlocate is working well; people now complain about makewhatis taking long time instead of updatedb :) That's the mostly unbiased part, the rest is my, obviously biased, opinion. I have now taken a very quick look at rlocate; note that I haven't actually tried it. - rlocate requires it's own kernel module; the Fedora kernel maintainers frown on external modules, why isn't it merged upstream? - "At the moment the stacking with other security modules is not implemented", in other words rlocate can't be used with SELinux. - I'd like to see some numbers. Was the run-time overhead ever measured? - The rlocate module uses \n to separate reported paths, but \n is a valid filename character. (This is of course fixable and not a long-term concern, but it worries me such bugs are there after a year of public releases.) - The code is based on slocate. One of the benefits of mlocate is that it is not based on slocate :) Basically the only part of slocate that could be reused in mlocate was configuration parsing and exclusion handling, and that code was really better to rewrite from scratch (e.g. look at #135952). Call that NIH if you want. Generally, I think mlocate and Beagle together cover the problem space quite well: Beagle is the "GUI search", full-featured, for people that need to get their work done and don't worry about every last bit of performance. mlocate is the exact opposite, for command-line users who know the limitations and are prepared to accept them in exchange for almost no overhead. I'd hate to run a daemon snooping on all file activity only to run a few locate searches for non-moving system files a week; I happen to know where my own files are. Finally, "Why isn't Fedora moving to rlocate?" is not the right question. I don't think it was ever decided that "Fedora isn't moving to rlocate"; in particular I'm sure a Fedora Extras package of rlocate would be welcome, then we would have something to compare. Mirek From chitlesh at fedoraproject.org Wed Feb 22 00:34:38 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 22 Feb 2006 01:34:38 +0100 Subject: Non-free Extras? In-Reply-To: <43FBAD03.3000305@gmail.com> References: <43FBA1CD.4020908@gmail.com> <43FBAD03.3000305@gmail.com> Message-ID: <13dbfe4f0602211634n41846666wbd0531114a674e63@mail.gmail.com> > > Not speaking as an authority, but such notions are directly against > > the stated goals of this project. The fact that there are some > > people who want to also use non-free software doesn't (and > > shouldn't) change the nature or goals of the project itself. Those > > who want to do so should create a central repository themselves and > > provide whatever guarantees they can muster. It's not likely to > > ever be able to use Fedora branding though. > > > > Sean True, its directly against the stated goals of this project. -- http://clunixchit.blogspot.com From seanlkml at sympatico.ca Tue Feb 21 23:58:49 2006 From: seanlkml at sympatico.ca (sean) Date: Tue, 21 Feb 2006 18:58:49 -0500 Subject: Non-free Extras? In-Reply-To: <43FBA1CD.4020908@gmail.com> References: <43FBA1CD.4020908@gmail.com> Message-ID: On Tue, 21 Feb 2006 18:27:09 -0500 Eric Mesa wrote: > Hash: SHA1 > > In order to pull in packagers like those maintaining Dries, Dag Weirs, > freshrpms, and others, and in order to assure Fedora users that their > packages would work instead of saying, "if you don't use official > packages, you're on your own," has there been any conversation on > taking an example from Debian and having a non-free repository? It > would also free up the packagers who spend so much time duplicating > each other's packages in order to ensure compatibility. I know there > are issues with their ffmpeg and mp3 codecs, but could these issues be > solved simply by designating their repositories as non-free? I think > it would greatly enhance the Fedora experience, IMHO as a loyal FC > user since Yarrow. > Not speaking as an authority, but such notions are directly against the stated goals of this project. The fact that there are some people who want to also use non-free software doesn't (and shouldn't) change the nature or goals of the project itself. Those who want to do so should create a central repository themselves and provide whatever guarantees they can muster. It's not likely to ever be able to use Fedora branding though. Sean From fedora-devel-list at cygnusx-1.org Wed Feb 22 01:08:27 2006 From: fedora-devel-list at cygnusx-1.org (Nathan Grennan) Date: Tue, 21 Feb 2006 17:08:27 -0800 Subject: rlocate vs. mlocate In-Reply-To: <43FBAF24.5000607@volny.cz> References: <43FB5C68.8070205@cygnusx-1.org> <43FBAF24.5000607@volny.cz> Message-ID: <43FBB98B.4060300@cygnusx-1.org> Miloslav Trmac wrote: > Some history: > > I decided to write mlocate as a "for fun" project at the time an > audit-based locate replacement was proposed for the Summer of Code, in > order to have something different for speed comparison. I did look at > existing alternatives with minimal run-time overhead (the possible > audit-based locate would have an always-running daemon); a kernel module > and a daemon didn't fit my idea of minimal overhead, so I have ignored > rlocate. > > I was ready to write off the development time of mlocate as a "personal > fun project, not paid by Red Hat", if it wouldn't be a noticeable > improvement. > > The decision happened basically like this: > mitr> I'd like to replace slocate by mlocate for FC5 and beyond. > mitr> [mlocate is a noticeable incremental improvement over slocate]. > decision makers> OK, makes sense. > > It seems mlocate is working well; people now complain about makewhatis > taking long time instead of updatedb :) > > > That's the mostly unbiased part, the rest is my, obviously biased, opinion. > > > I have now taken a very quick look at rlocate; note that I haven't > actually tried it. > > - rlocate requires it's own kernel module; the Fedora kernel maintainers > frown on external modules, why isn't it merged upstream? > - "At the moment the stacking with other security modules is not > implemented", in other words rlocate can't be used with SELinux. > - I'd like to see some numbers. Was the run-time overhead ever > measured? > - The rlocate module uses \n to separate reported paths, but \n is > a valid filename character. (This is of course fixable and not > a long-term concern, but it worries me such bugs are there after > a year of public releases.) > - The code is based on slocate. One of the benefits of mlocate is that > it is not based on slocate :) Basically the only part of slocate that > could be reused in mlocate was configuration parsing and exclusion > handling, and that code was really better to rewrite from scratch > (e.g. look at #135952). Call that NIH if you want. > > > Generally, I think mlocate and Beagle together cover the problem space > quite well: Beagle is the "GUI search", full-featured, for people that > need to get their work done and don't worry about every last bit of > performance. mlocate is the exact opposite, for command-line users who > know the limitations and are prepared to accept them in exchange for > almost no overhead. > > I'd hate to run a daemon snooping on all file activity only to run a few > locate searches for non-moving system files a week; I happen to know > where my own files are. > > Finally, "Why isn't Fedora moving to rlocate?" is not the right > question. I don't think it was ever decided that "Fedora isn't moving > to rlocate"; in particular I'm sure a Fedora Extras package of rlocate > would be welcome, then we would have something to compare. > Mirek Ah, just for the type of response I was hoping for and expected. If rlocate uses a kernel module, instead of inotify, then I agree it isn't ideal. I would say as expected the focus is too much in the gritty programming details, and not the big picture which tends to be a common problem. It sounds like someone still needs to write a inotify version of locate. I have no problem with a light weight daemon that would just reindex the locate database based on information feed to it by the kernel via inotify. It would be an almost instantaneous replacement for both find and locate. I don't think beagle is quite the proper solution, at least from what I have seen of it. It is too focused on file formats and searching inside the file, where as most of the time you just need to find the file by name, especially as root. Another nice thing would be if such a daemon existed, tie find into for the more powerful searches based on more than just filename. I think that would settle the issue completely. From hhoffman at ip-solutions.net Wed Feb 22 01:06:35 2006 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Tue, 21 Feb 2006 20:06:35 -0500 Subject: xenguest-install.py on FC5-t3 In-Reply-To: <43FBADAB.2050706@fedoraproject.org> References: <43FBAB76.2040301@ip-solutions.net> <43FBADAB.2050706@fedoraproject.org> Message-ID: <43FBB91B.8020301@ip-solutions.net> aha! so, if I want to install a older version, namely FC4, then I should use the method of installation in the FC4 Xen guide? Thanks, Harry Rahul Sundaram wrote: > Harry Hoffman wrote: > >> Hi, >> >> I'm looking at the Quickstart under FC5 for Xen and running into trouble. >> >> I've created a disk image using dd to a file and am now stuck as to >> where I get the install media. >> >> Can anyone provide a pointer for what args I should be supplying this >> script? >> >> Below is what I tried. >> >> Thanks, >> Harry >> >> >> [root at n1-22-30 ~]# xenguest-install.py >> What is the name of your virtual machine? ldap >> How much RAM should be allocated (in megabytes)? 256 >> What would you like to use as the disk (path)? /srv/xen/ldap/ldap.xen >> Invalid source specified. Please specify an NFS, HTTP, or FTP install >> source >> What is the install location? >> http://download.fedora.redhat.com/pub/fedora/linux/core/4/i386/os/ >> http://download.fedora.redhat.com/pub/fedora/linux/core/4/i386/os/ >> Traceback (most recent call last): >> > Try > http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/ > From mitr at volny.cz Wed Feb 22 01:32:45 2006 From: mitr at volny.cz (Miloslav Trmac) Date: Wed, 22 Feb 2006 02:32:45 +0100 Subject: rlocate vs. mlocate In-Reply-To: <43FBB98B.4060300@cygnusx-1.org> References: <43FB5C68.8070205@cygnusx-1.org> <43FBAF24.5000607@volny.cz> <43FBB98B.4060300@cygnusx-1.org> Message-ID: <43FBBF3D.2030006@volny.cz> Nathan Grennan napsal(a): > I would say as expected the focus is too much in the gritty > programming details, and not the big picture which tends to be a common > problem. Sometimes it turns out the great "big picture" is unimplementable because of a "gritty programing detail" :) > It sounds like someone still needs to write a inotify version of > locate. I have no problem with a light weight daemon that would just > reindex the locate database based on information feed to it by the > kernel via inotify. I'm not an inotify expert, nevertheless I think there are two "gritty programming details" to solve. First, inotify doesn't work over network filesystems, so it isn't possible to guarantee instantaneous update in general, and a periodic scan is necessary anyway. Second, inodes of all watched directories have to be kept in memory; on my laptop that would be roughly 16000 inodes, which is about 10 MB of memory wasted for locate; consider a file server with a few terabytes of storage. (To prevent this pinning of kernel memory, inotify has a configurable limit on the number of watches, which is 8192 by default.) > It would be an almost instantaneous replacement for > both find and locate. No, find(1) is specified by SUSv3, which explicitly states "The find utility shall recursively descend the directory hierarchy...". Because other programs can detect whether find(1) was traversing the subtree, we can't optimize it out. > where as most of the time you just need > to find the file by name, especially as root. In my experience the file is not moving in these cases, but that's of course not a statistically relevant sample. Mirek From jwboyer at jdub.homelinux.org Wed Feb 22 01:05:01 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 21 Feb 2006 20:05:01 -0500 Subject: Non-free Extras? In-Reply-To: <1140565924.31940.17.camel@T7.Linux> References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> Message-ID: <1140570301.19186.3.camel@yoda.jdub.homelinux.org> On Tue, 2006-02-21 at 23:52 +0000, Paul F. Johnson wrote: > Hi, > > > In order to pull in packagers like those maintaining Dries, Dag Weirs, > > freshrpms, and others, and in order to assure Fedora users that their > > packages would work instead of saying, "if you don't use official > > packages, you're on your own," has there been any conversation on > > taking an example from Debian and having a non-free repository? It > > would also free up the packagers who spend so much time duplicating > > each other's packages in order to ensure compatibility. I know there > > are issues with their ffmpeg and mp3 codecs, but could these issues be > > solved simply by designating their repositories as non-free? I think > > it would greatly enhance the Fedora experience, IMHO as a loyal FC > > user since Yarrow. > > Personally, I'd love to see everything under one roof or failing that, > have freshrpms and livna have the equivalent of a rawhide build. http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/development/ These are not the packages you are looking for... josh From ericsbinaryworld at gmail.com Wed Feb 22 02:36:38 2006 From: ericsbinaryworld at gmail.com (Eric Mesa) Date: Tue, 21 Feb 2006 21:36:38 -0500 Subject: Non-free Extras? In-Reply-To: <1140570301.19186.3.camel@yoda.jdub.homelinux.org> References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> <1140570301.19186.3.camel@yoda.jdub.homelinux.org> Message-ID: <43FBCE36.4@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Josh Boyer wrote: > On Tue, 2006-02-21 at 23:52 +0000, Paul F. Johnson wrote: > >> Hi, >> >>> In order to pull in packagers like those maintaining Dries, Dag >>> Weirs, freshrpms, and others, and in order to assure Fedora >>> users that their packages would work instead of saying, "if you >>> don't use official packages, you're on your own," has there >>> been any conversation on taking an example from Debian and >>> having a non-free repository? It would also free up the >>> packagers who spend so much time duplicating each other's >>> packages in order to ensure compatibility. I know there are >>> issues with their ffmpeg and mp3 codecs, but could these issues >>> be solved simply by designating their repositories as >>> non-free? I think it would greatly enhance the Fedora >>> experience, IMHO as a loyal FC user since Yarrow. >> >> Personally, I'd love to see everything under one roof or failing >> that, have freshrpms and livna have the equivalent of a rawhide >> build. > > > http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/development/ > > These are not the packages you are looking for... > > josh > using the force there? q;o) - -- Eric Mesa ericsbinaryworld at gmail.com http://www.ericsbinaryworld.com Note: All emails from this address should have a GPG signature. If you have the proper setup you can use this to confirm my identity and that the email was not changed in transit. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFD+841PvU+8ApmWXIRAuEDAJkBy2E7qmQtBQw96rb6ymDfZ+j1WgCdGGM8 8jaIJ+dBBATqNPuA/IKIRAY= =nB/2 -----END PGP SIGNATURE----- From philipp_subx at redfish-solutions.com Wed Feb 22 02:34:20 2006 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Tue, 21 Feb 2006 19:34:20 -0700 Subject: Building Sunbird in FC3, FC4 Message-ID: <43FBCDAC.8020001@redfish-solutions.com> Has anyone successfully built Sunbird on fedora, and if so, do they have a .spec file they could publish that could conceivably be back-ported to FC3? Thanks, -Philip From rdieter at math.unl.edu Wed Feb 22 03:21:59 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 21 Feb 2006 21:21:59 -0600 Subject: Non-free Extras? In-Reply-To: <43FBA1CD.4020908@gmail.com> References: <43FBA1CD.4020908@gmail.com> Message-ID: <43FBD8D7.3080109@math.unl.edu> Eric Mesa wrote: > In order to pull in packagers like those maintaining Dries, Dag Weirs, > freshrpms, and others, and in order to assure Fedora users that their > packages would work instead of saying, "if you don't use official > packages, you're on your own," has there been any conversation on > taking an example from Debian and having a non-free repository? Yep: rpm.livna.org -- Rex From admin at ramshacklestudios.com Wed Feb 22 03:48:56 2006 From: admin at ramshacklestudios.com (Peter Gordon) Date: Tue, 21 Feb 2006 19:48:56 -0800 Subject: Licensing brainstorm In-Reply-To: <54284.217.33.199.77.1140538867.squirrel@mauro.ezplanet.net> References: <54284.217.33.199.77.1140538867.squirrel@mauro.ezplanet.net> Message-ID: <1140580136.5502.8.camel@tuxhugger> On Tue, 2006-02-21 at 16:21 +0000, Mauro Mozzarelli wrote: > [...] > > > > You can not bundle the GPL app and the proprietary lib together however. > I think that bundling together is a matter of interpretation, but what I > have understood, for example is that they cannot be in the same tarball > nor in the same srpm, but they can be in different tarballs on a CD. > > That's simply the "mere aggregation" clause, right? -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xDA3634D7 Fingerprint: 0629 F604 3C14 937E F088 E5E9 B3CB 48EC DA36 34D7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From rnicholsNOSPAM at comcast.net Wed Feb 22 05:15:08 2006 From: rnicholsNOSPAM at comcast.net (Robert Nichols) Date: Tue, 21 Feb 2006 23:15:08 -0600 Subject: Rawhide kickstart install did not exclude packages In-Reply-To: <20051121221436.GA5832@exeter.boston.redhat.com> References: <438244C3.5030700@cora.nwra.com> <20051121221436.GA5832@exeter.boston.redhat.com> Message-ID: Chris Lumens wrote: > Orion Poplawski wrote: > >>Just did a kickstart install of rawhide and it did not exclude the >>packages I had marked with "-name". Is this a known issue? > > > Package selection with kickstart is very much up in the air right now. > We haven't even worked on writing out the %packages section in the > generated ks file after installation yet. We'll get to work on the > kickstart package selection after test 1 is out of the way. Anything further on this? Here we are at FC5 test 3 and still no package exclusions or inclusions get written into the generated kickstart file during installation. -- Bob Nichols Yes, "NOSPAM" is really part of my email address. From dax at gurulabs.com Wed Feb 22 05:55:45 2006 From: dax at gurulabs.com (Dax Kelson) Date: Tue, 21 Feb 2006 22:55:45 -0700 Subject: FC5 test3 -- dmraid broken? In-Reply-To: <1140536181.20618.2.camel@localhost.localdomain> References: <1140499892.3430.13.camel@mentorng.gurulabs.com> <1140536181.20618.2.camel@localhost.localdomain> Message-ID: <1140587745.3551.20.camel@mentorng.gurulabs.com> On Tue, 2006-02-21 at 10:36 -0500, Peter Jones wrote: > On Mon, 2006-02-20 at 22:31 -0700, Dax Kelson wrote: > > > mkdmnod > > mkblkdevs > > rmparts sda > > rmparts sdb > > dm create nvidia_hcddcidd 0 586114702 mirror core 2 64 nosync 2 8:16 0 8:0 0 > > dm partadd nvidia_hcddcidd > > echo Scanning logical volumes > > lvm vgscan --ignorelockingfailure > > echo Activating logical volumes > > lvm vgchange -ay --ignorelockingfailure VolGroup00 > > resume /dev/VolGroup00/LogVol01 > > Ok, so this does all look fine -- can you add some sleeps in here and > see if you can copy down exactly what these output, and see which one > actually fails? > > If that fails we can build you an initrd by hand that has tools in it... > -- > Peter I added echos such as "about to dm create" and then some "sleep 5" after each of those commands. There is zero output from mkdmnod on down until the "lvm vgscan" runs. It produces this output: device-mapper: 4.5.0-ioctl (2005-10-04) initialised: dm-devel at redhat.com Reading all physical volumes. This may take a while... No volume groups found Unable to find volume group "VolGroup00" ... Booting into the rescue environment the dm raid is brought up and LVM activated automatically and correctly. Incidentally in the rescue environment I chrooted into my rootfilesytem and brought up my network interface (/etc/init.d/network start), and ran yum -y update. There were about 40 packages downloaded, but every rpm install attempt puked out out with errors from the preinstall scripts. Unsurprisingly running rpm -Uvh /path/to/yum/cache/kernel*rpm resulted in the same error. :( Dax Kelson From tadams-lists at myrealbox.com Wed Feb 22 07:00:40 2006 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Wed, 22 Feb 2006 00:00:40 -0700 Subject: Ralink rt2500, can't load module In-Reply-To: <1140559789.3082.37.camel@laptopd505.fenrus.org> References: <43FB7DC9.8060307@vip.hr> <1140559789.3082.37.camel@laptopd505.fenrus.org> Message-ID: <1140591640.2284.13.camel@aurora.localdomain> This is a bug in rt2500. I reported it. It has to do with module_param call not following the new standard. They have not fixed this problem even though I reported it with a fix. I patched my own but am no longer using the card (though when master mode works I will switch back due to my preference for completely open source drivers instead of partially one way or the other. I suggest you ask them to fix it up for newer kernels. The problem is in their MODULE_PARAM calls. Trever On Tue, 2006-02-21 at 23:09 +0100, Arjan van de Ven wrote: > On Tue, 2006-02-21 at 21:53 +0100, Igor Jagec wrote: > > I compiled beta3 and cvs drivers on FC5t3 and everything went ok, but > > the rt2500 module can't be loaded. On FC5t2's default kernel everything > > went ok (both, compiling and loading the rt2500 module). > > > > [root at localhost Module]# /sbin/modprobe rt2500 > > FATAL: Error inserting rt2500 > > (/lib/modules/2.6.15-1.1955_FC5/extra/rt2500.ko): Invalid argument > > look in dmesg output for a more descriptive reason for the failure > -- "He who chops his own wood, is warm twice." -- Abraham Lincoln From mharris at mharris.ca Wed Feb 22 07:21:25 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Wed, 22 Feb 2006 02:21:25 -0500 Subject: closing older bug reports without looking = bad practice ? In-Reply-To: <1140463650.3252.30.camel@mariusa-ro.ro.oracle.com> References: <1140463650.3252.30.camel@mariusa-ro.ro.oracle.com> Message-ID: <43FC10F5.6090206@mharris.ca> Preface: My response is rather verbose, because I believe this is a very important issue, and is one I've put a tremendous amount of thought and effort into for the last 2-4 years, so I have a lot of ideas and opinions to express. Those who dislike long emails, or aren't interested in the topic of bug triage, are encouraged to stop reading right now. ;o) Marius Andreiana wrote: > Hi all, > > I've got a bunch of notices with FC5 test1 and test2 bugs being closed > as there have been a lot of updates meanwhile. For me, as a tester which > monitors some of the bugs and find some time once in a weekend to do > some triage, this seemed plain rude. I agree. > If there are too many bugs overwhelming developers then the cause should > be addressed (better code with fewer bugs, which means more resources > devoted to coding which are unavailable now) or find alternative > solutions, where fedora testers could help. Better code with fewer bugs is somewhat of a pipe dream. In particular since the software is written by various random people scattered around the globe who can't be forced by the Fedora Project to write better code. Adding more engineers to the problem would at least in theory fix more bugs, but would also likely introduce some new bugs that were not previously there before. IMHO at least, that wouldn't significantly impact the bug-freeness of most things anyway. If you have 500 bugs in something and 10 people spend a lot of time developing/fixing it, and you add 5 more people, and that lowers the overall bug count down to 485 bugs, while you've improved the software, it is still quite buggy. Adding another 100 engineers to every project is not financially viable, and wouldn't solve the problem anyway, as adding more people to solve problems reaches a certain point in which adding one more person actually makes things worse. Brooks law. The right approach I believe, is to very clearly define the real core problems that need to be solved, get a laundry list, and then seriously brainstorm other ideas openly as to how to solve the laundry list problems. While brainstorming however, one needs to be very very careful that they are not just solving the bullet-list of problems, but also avoiding creating NEW problems which are WORSE in the process (like the autoclosing that just happened.) > Closing all the reported bugs won't make them go away, but will make testers > go away. With the current bugzilla setup, the number of reported bugs would have > decreased as more testers do triage and see if they are still valid in > rawhide, or they could confirm it until a developer finally looks at it, or the > reporter might update it with new info. At a bare minimum, such mass bug updates shouldn't be blindly applied to groups of bugs, but should be done by reviewing each bug individually. Reviewing a large number of bugs and earmarking them (on paper, or in a text file, or on a bugzilla bug tracker, or some other mechanism) for later mass-update is a way of categorizing smartly, however it does take more human time and effort. Then, a mass update could be applied to all of the bugs that were earmarked. Then the comment added actually makes sense, and is in context of the current state of the bugs that get flagged. > A practice from openoffice bugzilla could be borrowed - bugs reported by > usual bugzilla acounts are by default UNCONFIRMED, and only fedora > testers can set them to NEW. If there are too many bugs, a developer > could ignore UNCONFIRMED ones. I don't really like the idea of an UNCONFIRMED state personally, at least as far as X related bug reports are concerned. Sometimes people report bugs, and someone else has the same problem as them or *THINKS* they do, and could in theory "confirm" it. Later the "bug" turns out to be 5 people all misconfigured the same thing, or simply misunderstand how it is supposed to work. That's one example. The current text comments indicate who has confirmed what, etc. anyway and in a more meaningful way. And for X bugs, I would say the majority are "UNCONFIRMED" for most of their life from engineering side at least, due to lack of hardware and various numerous other factors. The last thing we really need is more bugzilla bug states/resolutions. It is a huge morass of confusing states as it is right now, and if you ask 20 people what each state really means, you'll get 20 different answers for many of the states. Bug state usage varies heavily from package to package, and from engineer to engineer. That's just a fact of current and past usage that can't be ignored. One could put forth the idea of "Well let's make some policies to officially define exactly what each bug state/resolution means, and document them on a Wiki, and declare it official policy. Then after that every single engineer will be ruled with an iron fist to use the bug states 100% consistently." Actually, some people have put that idea forth. The problem is, it is like preventing people from smoking pot by making possession of pot illegal. It doesn't stop anything. No matter what documentation and/or policies might be created for bugzilla, it will have some net positive effect perhaps, but many people will likely just ignore a lot of it due to information-overflow and the need to get real work done. In the end, people's job priorities win over reciting and adhering a bugzilla manual from heart like a national anthem. > I also noticed Dave closes kernel bugs with each kernel release, asking > people to retest. While this might save developers time, it could also > leave real bugs closed as reporter might get tired of re-confirming a > bug for 3 times. That is indeed true, however there is really no perfect solution to the bug triage problem, and it is largely left in the hands of the individual package maintainers to determine how best to manage the bugs in the components that they own. For smaller packages it is much less of a problem. For huge critical packages like the kernel, X, rpm, anaconda, glibc, gcc, gnome, kde, and others, there are so many bugs that it is just insane bug pileup that is impossible to know what is still relevant and what is not. And the more bugs there are piled up, the more difficult it is to find the ones that are actually still relevent and prioritize them effectively. For example, you have 700 bugs open in your packages total. Today it is your task to prioritize them. The only problem is that it will take you 3 weeks simply to read/review each bug to even know what all is there, and to start to build up a list of bugs which are more serious and deserve more attention. While you are doing that, 72 new bugs have been filed. All of this time you have done nothing but read/triage and update bug reports, trying to categorize them in some sane manner to work on them _later in the future_. It's just totally an unmanageable mountain of infinite problems for all intents and purposes. Yet, you still have to wade through at least a _fraction_ of all of the problems, and flag them as being priorities, and put them in your work queue. Then you need to actually _work_ on that work queue. While working on actually fixing bugs, the existing bugs continue to rot, and pile up while 50 more come in. Also, for the kernel and X at least, add to that the fact that you don't have every network card, video card, motherboard, laptop, mouse, KVM switch, monitor, DFP, sound card, etc. available for you to even attempt to reproduce the problem being reported, and there is a whole new class of bugs that pile up. One attempt at helping to solve this, is for the engineer to ask the person to please report their bug to the upstream project, as that increases the chances that someone who actually has the hardware available, might also have the time available to look into the problem, and actually fix it. Sometimes that works great. Other times, the bug reporter whines that they have done their job reporting it to Red Hat, and don't want to be bothered opening 400 bugzilla accounts around the globe. Ok, no problem... your bug is now 1 bug in 750, of which maybe 50 get fixed in N months or whatever. Your bug might sit there for a year, or two simply due to insufficient hardware or manpower, or perhaps it is just very low priority when compared to 50 other higher more critical issues that are also sitting rotting. Since finite humans can only solve finite numbers of problems in finite amount of time, and software flaws are seemingly infinite, the bugs will continue to pile up and pile up forever essentially. The only way to prevent it as I personally see it, is to have a bug triaging "method" which makes concrete decisions at regular intervals throughout a bug's life. I've talked about this before a year or two ago on various lists when we implemented such a system for our team's bug triaging. I wont get into the details of that system right now, or this already long mail will be a textbook. ;o) > Take for example this bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174968 > In FC5test1, looks like the bttv driver had some problems, causing > tvtuners to stop working. A few updates later, it worked again. The > causes for not working and working again are unknown, therefore it could > happen on every new release. Just cross fingers and hope for the best! Yep, and unfortunately that's the way it is for a lot of hardware class bugs. I'll just make up a completely fabricated example to illustrate my point. Let's say you have a Trident video card, or perhaps a Siliconmotion video in a laptop. You install FC5test3 on it, and video doesn't work properly. Well, to the best of my knowledge, none of our X engineers including myself have any Trident video hardware whatsoever, nor siliconmotion. No trident or siliconmotion hardware documentation. Just driver source code, and no way to attempt to reproduce the problem. The only way to diagnose it usually is to read the symptoms and gather more information such as logs/configs. Then review all the info that's been accumulated and form a theory as to what the problem might be based on the info provided. Then when possible provide suggestions of things to try to narrow down the problem and perhaps find a temporary workaround. Quite often, such bugs will never get fixed until the upstream X.Org driver maintainer who _does_ have the hardware, and _does_ have the documentation is aware of the issue, and provides a fix or test-fix in CVS or in an upstream bug report. So the reality of things is that some bugs will get fixed, some will get workarounds, some will get ugly hacks that allow the person to be able to use their system perhaps with degraded functionality or performance until a real fix is available upstream. Other problems will sit and rot due to being very obscure, hard to reproduce, very transient and require specific hardware combinations, or require hardware that isn't available. Other bugs are just very very low priority compared to the other 500 bugs that are open in the grand scheme of things, and so we know right away there's no way we'll ever have a chance of spending time on it. File a bug in our bugzilla about the ark logic driver for example and I can pretty much guarantee that it will either sit there forever, or I'll close it "please file upstream". "Please file upstream" is a nice polite way of saying "I want your problem to be solved too, but being completely realistic, if I don't tell you to file it upstream right now, the likelyhood of it sitting in our bugzilla untouched and unfixed for 3 years is about 1000 times more likely than if it is filed upstream, simply due to manpower and resource constraints." I realize this is a _LOT_ more information that some people reading this may want to read, and I'm sure that some people will probably be upset to read about the cold hard reality that it is simply impossible for every single bug to get attention. Everyone wants their problems to be looked at at least, and it's nice if you can do it in a one stop shopping manner through your distro's bugzilla. Hell, even *I* want that!! Don't we all! Reality kicks in though, and you either end up going from 500 bugs to 800 to 2000 to 3000 and at some point you get zero actual work done because you spend all your time reading bug reports and no actual time fixing bugs. Or you devise a scheme for reducing the bug load by telling people to upstream things, closing bugs to which the reporter(s) have not been responsive for N days/weeks/months, closing bugs as rawhide that you have good reason to believe are fixed in the latest bits - with a request to reopen if the problem still exists, etc. Many teams or individuals have a system of some sort for handling that. Others might just let those bugs pile up for a long time, then gang close many at once. No matter how it is done, some people will no doubt be inconvienienced, and it is probably not possible to avoid that completely. > To conclude, please don't close bug reports without researching them > first. In general I agree with that. I dislike the idea of an auto-close after n days/weeks/months of bugs of category foo, or release bar, or test release bar, etc... as there will always be bugs closed and lost forever that nobody will even notice got closed, but which were definitely not fixed and shouldn't have been closed. > If Red Hat staff doesn't have time for it, please ask for triage > help on fedora-test list, even with weekly themes, such as GNOME triage > week (including searching for upstream bugs), kernel week etc - just > post the link to the bugzilla query for all the required components. Agreed. A bug day/days/week/month/whatever is a better way to approach it IMHO for many cases. > Thanks and looking forward for a better FC5 release! Indeed. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From jkeating at redhat.com Wed Feb 22 07:42:01 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 21 Feb 2006 23:42:01 -0800 Subject: rawhide report delayed Message-ID: <1140594121.17286.161.camel@ender> We're having some issues getting rawhide pushed tonight. It may be delayed for a few hours yet. Please be patient w/ us, thanks! -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Wed Feb 22 08:16:50 2006 From: j.w.r.degoede at hhs.nl (Goede, J.W.R. de) Date: Wed, 22 Feb 2006 09:16:50 +0100 Subject: Non-free Extras? In-Reply-To: References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> Message-ID: On Tue, 21 Feb 2006 18:55:49 -0500 "Gregory Maxwell" wrote: > On 2/21/06, Paul F. Johnson > wrote: > > Personally, I'd love to see everything under one roof > or failing that, > > have freshrpms and livna have the equivalent of a > rawhide build. > > Most of the external archives are almost completely > useless to those > who wish to, or must, keep their system of unfree > software because > there is no way to inhibit the random stray dependency > from sucking in > a lot of non-free stuff. > Agreed, Talking about solutions and not problems I propose: -Fedora Extras (as is) -Fedora Patent Encumbered (better name) aka Debian non-US -Fedora Non Commercial -Fedora Non Free Livna could very well keep serving as the Patent Encumbured place, The Fedora Project should not occupy itself with (too much) discussion about this, since we don't want to be involved in _any_ way. I'm just mentioning this one for completeness. Non Commercial should hold to much discussed already almost free software with some kinda not for commercial use clause, putting this here also makes it easier for CD creators to not burn themselves. This could be filled for starters with some programs from Livna which match these criteria, making Livna a pure patent poluted repo, instead of the mix its becoming now. Non Free would be for truly non Free software, so even more restrictive then no commercial use and even without source say for example binary gfx card drivers. We would then also need to add dependency rules, even if the license is 100 free then if: All deps in core or extras -> package in extras it has Non Free deps -> non Free repo it has Non-commercial deps -> no Commercial use repo Regards, Hans From avi at argo.co.il Wed Feb 22 08:23:03 2006 From: avi at argo.co.il (Avi Kivity) Date: Wed, 22 Feb 2006 10:23:03 +0200 Subject: Non-free Extras? In-Reply-To: References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> Message-ID: <43FC1F67.7080607@argo.co.il> Goede, J.W.R. de wrote: >Talking about solutions and not problems I propose: >-Fedora Extras (as is) >-Fedora Patent Encumbered (better name) aka > Debian non-US >-Fedora Non Commercial >-Fedora Non Free > > We would also need -Fedora for Non-Lawyers for ordinary users. How is one supposed to figure out where to look for things, and what all these repositories mean? This should be kept simple. -- error compiling committee.c: too many arguments to function From j.w.r.degoede at hhs.nl Wed Feb 22 08:23:44 2006 From: j.w.r.degoede at hhs.nl (Goede, J.W.R. de) Date: Wed, 22 Feb 2006 09:23:44 +0100 Subject: Non-free Extras (No commercial use?) ? In-Reply-To: <43FBAD03.3000305@gmail.com> References: <43FBA1CD.4020908@gmail.com> <43FBAD03.3000305@gmail.com> Message-ID: On Tue, 21 Feb 2006 19:14:59 -0500 Eric Mesa wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > sean wrote: > > > On Tue, 21 Feb 2006 18:27:09 -0500 Eric Mesa > > wrote: > > > >> Hash: SHA1 > >> > >> In order to pull in packagers like those maintaining > Dries, Dag > >> Weirs, freshrpms, and others, and in order to assure > Fedora users > >> that their packages would work instead of saying, "if > you don't > >> use official packages, you're on your own," has there > been any > >> conversation on taking an example from Debian and > having a > >> non-free repository? It would also free up the > packagers who > >> spend so much time duplicating each other's packages > in order to > >> ensure compatibility. I know there are issues with > their ffmpeg > >> and mp3 codecs, but could these issues be solved > simply by > >> designating their repositories as non-free? I think it > would > >> greatly enhance the Fedora experience, IMHO as a loyal > FC user > >> since Yarrow. > >> > > > > Not speaking as an authority, but such notions are > directly against > > the stated goals of this project. The fact that there > are some > > people who want to also use non-free software doesn't > (and > > shouldn't) change the nature or goals of the project > itself. Those > > who want to do so should create a central repository > themselves and > > provide whatever guarantees they can muster. It's not > likely to > > ever be able to use Fedora branding though. > > > > Sean > > > I figured. I thought it was worth asking, just in case. > Good point! Still I see a demand for this and much of the infrastructure is there already with FE, we just need additonal repos. There are people interested in this, and it would be a waste of community effort to let them setup there own build infrastructure and everything that comes with it. Now if we're crossing a legal treshold by offering them infrastructure then I agree 100% but if we can legally help them by offering infrastructure, why not. I've not thought about branding yet, maybe non-free needs a non fedora name, I'm personally not all that interested in non-free, as I won't use it. What I'm interested in is no commercial use, this is so close to 100% free (for me as an acedemic / private user) I see a place for this under the Fedora Project. Also (I'll take this discussion to the Livna list after this mail since it doesn't belong here) I would like to see livna cleaned-up / split so that livna users don't have to worry about what they're sucking in through yum, currently livna is (IMHO) becoming to much of a mixed bag. Regards, Hans > - -- > Eric Mesa > ericsbinaryworld at gmail.com > http://www.ericsbinaryworld.com > Note: All emails from this address should have a GPG > signature. If > you have the proper setup you can use this to confirm my > identity and > that the email was not changed in transit. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.1 (GNU/Linux) > Comment: Using GnuPG with Fedora - > http://enigmail.mozdev.org > > iD8DBQFD+60CPvU+8ApmWXIRAq//AJ91nwuJJX5pbKg7IcKdlhNcq9MzxACfY7N5 > xLFvCzeiQ/+hHi1RDcVufNs= > =4Tax > -----END PGP SIGNATURE----- > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From arjan at fenrus.demon.nl Wed Feb 22 09:01:58 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Wed, 22 Feb 2006 10:01:58 +0100 Subject: Licensing brainstorm In-Reply-To: <1140580136.5502.8.camel@tuxhugger> References: <54284.217.33.199.77.1140538867.squirrel@mauro.ezplanet.net> <1140580136.5502.8.camel@tuxhugger> Message-ID: <1140598918.2979.7.camel@laptopd505.fenrus.org> On Tue, 2006-02-21 at 19:48 -0800, Peter Gordon wrote: > On Tue, 2006-02-21 at 16:21 +0000, Mauro Mozzarelli wrote: > > [...] > > > > > > You can not bundle the GPL app and the proprietary lib together however. > > I think that bundling together is a matter of interpretation, but what I > > have understood, for example is that they cannot be in the same tarball > > nor in the same srpm, but they can be in different tarballs on a CD. > > > > > That's simply the "mere aggregation" clause, right? it's an oversimplification of that clause. "on the same cd" is only valid if it's really independent works, in fact "part of the same work" is conditional on that. Fedora is a work, so are many other things. (and "independent" is key here; for example it'll be really hard to argue that say a kernel module is independent of the kernel on the same cd set, while it'll not be hard to argue that an Oracle DB is independent from MySQL on the same cd set. Where the boundary is... tricky and you should talk to a lawyer if you want to get close to this edge) From rmy at tigress.co.uk Wed Feb 22 09:51:04 2006 From: rmy at tigress.co.uk (Ron Yorston) Date: Wed, 22 Feb 2006 09:51:04 GMT Subject: The future of Linux - architecture and package inter-dependencies Message-ID: <200602220951.k1M9p4Yh015409@tiffany.internal.tigress.co.uk> Alan Cox wrote: >It is anyway, does anyone use motif ? as far as I can see its a good >extras candidate We have millions of lines of code ported over from *nix that use Motif. And I'm sure we're far from alone in that. Now, Fedora Core isn't a platform we support, but we do support RHEL. So, thinking ahead, if OpenMotif is moved to Extras in FC6 or FC7 what happens to it in RHEL6 (or whatever)? The Fedora Project doesn't need to worry about supporting Red Hat's paying customers, but Red Hat does. Ron From rmy at tigress.co.uk Wed Feb 22 09:59:08 2006 From: rmy at tigress.co.uk (Ron Yorston) Date: Wed, 22 Feb 2006 09:59:08 GMT Subject: rlocate vs. mlocate Message-ID: <200602220959.k1M9x8ge015416@tiffany.internal.tigress.co.uk> Miloslav Trmac wrote: >It seems mlocate is working well; people now complain about makewhatis >taking long time instead of updatedb :) Yes, mlocate is definitely a Good Thing. And add me to the list of people complaining about makewhatis. But don't forget prelink. I turn it off. When I remember. Usually a couple of seconds after anacron has started its latest attempt to drain my battery. Ron From gauret at free.fr Wed Feb 22 10:05:09 2006 From: gauret at free.fr (Aurelien Bompard) Date: Wed, 22 Feb 2006 11:05:09 +0100 Subject: Multiple concurrent versions of Python Message-ID: Hello y'all, During the event "Solutions Linux" in Paris, I met a Zope developper who had very good arguments on how Fedora could be improved to support more Python applications (and Zope in particular). Since Fedora is rather python-oriented, and we're considering Zope for our CMS, I think we should consider this. I maintain the Zope & Plone packages in Extras, and I must say it's complicated, because Zope requires specific versions of python (not the latest) and Plone requires specific versions of Zope : - Latest Plone requires Zope 2.8.5 (http://plone.org/products/plone/releases/2.1.2) - Latest Zope is 2.9, which works with python 2.4.2, but zope 2.8.5 is unsupported on python 2.4, it requires python 2.3.4 (http://www.zope.org/Products/Zope/2.8.5/Zope-2_8_5-released) Since Fedora only ships python 2.4, there is no way for the Zope & Plone packages to run on a supported python. The solution discussed with the Zope dev would be to ship python 2.3.5. There is a way to ship both versions, using the "alternatives" system (like sendmail and postfix). The symlink would be on /usr/bin/python and /usr/bin/python2. The only problem is with python modules and python applications which install files in /usr/lib/python2.4 - python modules should be compiled for both versions of python ex: python-imaging and python23-imaging - python applications installing files in /usr/lib/python2.4 should not have #!/usr/bin/python in the shebang, but the required version : #!/usr/bin/python2.4 and the package should require python24. The current python rpm could Provide python24. This is the way Debian does it, for example. And it works :) Since installing concurrent versions of python is technically possible, do you think this could be done in Fedora (of course, I'm not talking FC5 here) ? What do you think ? Any corner cases ? Regards, Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." -- Rich Cook From naoki at valuecommerce.com Wed Feb 22 10:17:46 2006 From: naoki at valuecommerce.com (Naoki) Date: Wed, 22 Feb 2006 19:17:46 +0900 Subject: xmms fonts in playlist broken (just me?) Message-ID: <1140603466.2384.204.camel@dragon.sys.intra> Latest rawhide (yesterday), xmms-1.2.10-20.fc5 Screen shot here if you want to see it : http://randomman.net/Screenshot-XMMS%20Playlist.png From kzak at redhat.com Wed Feb 22 10:27:11 2006 From: kzak at redhat.com (Karel Zak) Date: Wed, 22 Feb 2006 11:27:11 +0100 Subject: xenguest-install.py on FC5-t3 In-Reply-To: <43FBB91B.8020301@ip-solutions.net> References: <43FBAB76.2040301@ip-solutions.net> <43FBADAB.2050706@fedoraproject.org> <43FBB91B.8020301@ip-solutions.net> Message-ID: <1140604031.30120.42.camel@petra> On Tue, 2006-02-21 at 20:06 -0500, Harry Hoffman wrote: > aha! so, if I want to install a older version, namely FC4, then I should > use the method of installation in the FC4 Xen guide? There's no xen install images for FC4. It's new in FC5. Karel -- Karel Zak From benjy.grogan at gmail.com Wed Feb 22 10:03:52 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Wed, 22 Feb 2006 05:03:52 -0500 Subject: Non-free Extras? In-Reply-To: <43FC1F67.7080607@argo.co.il> References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> <43FC1F67.7080607@argo.co.il> Message-ID: On 2/22/06, Avi Kivity wrote: > > Goede, J.W.R. de wrote: > > >Talking about solutions and not problems I propose: > >-Fedora Extras (as is) > >-Fedora Patent Encumbered (better name) aka > > Debian non-US > >-Fedora Non Commercial > >-Fedora Non Free > > > > > We would also need > -Fedora for Non-Lawyers > > for ordinary users. How is one supposed to figure out where to look for > things, and what all these repositories mean? This should be kept simple. > Is there a way of including proprietary drivers with the Fedora Project? In time, Nvidia, ATI et al will definitely have the best available linux drivers for their hardware so it seems inevitable that proprietary drivers will have to be included in Fedora. They're giving away their drivers for free anyways. Benji -------------- next part -------------- An HTML attachment was scrubbed... URL: From pknirsch at redhat.com Wed Feb 22 10:36:58 2006 From: pknirsch at redhat.com (Phil Knirsch) Date: Wed, 22 Feb 2006 11:36:58 +0100 Subject: Results for install and remove tests for FC-Devel Message-ID: <43FC3ECA.9020100@redhat.com> Hi folks. As i've written last Friday, i have been running a complete install and removal test for all packages of the Friday snapshot of FC-Devel. Here the result summary: 176 distinct failures 93 failures because of missing PreReq: coreutils (various commands in scripts not available during install or erase) 53 failures because of missing PreReq: hicolor-icon-theme or using --ignore-theme-index for gtk-update-icon-cache 20 failures because of missing PreReq: chkconfig 5 failures because of missing PreReq: info 2 failures because of missing PreReq: selinux-policy-targeted 1 failures because of missing PreReq: scrollkeeper 1 failures because of a typo in a script 1 failures because of wierd ldconfig problem (most likely test bug) I've attached the whole list to this email. 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. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: install-test-results2.txt URL: From gnomeuser at gmail.com Wed Feb 22 10:50:27 2006 From: gnomeuser at gmail.com (David Nielsen) Date: Wed, 22 Feb 2006 11:50:27 +0100 Subject: Non-free Extras? In-Reply-To: References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> <43FC1F67.7080607@argo.co.il> Message-ID: <1140605428.24450.21.camel@price.stavtrup-st.dk> ons, 22 02 2006 kl. 05:03 -0500, skrev Benjy Grogan: > > > On 2/22/06, Avi Kivity wrote: > Goede, J.W.R. de wrote: > > >Talking about solutions and not problems I propose: > >-Fedora Extras (as is) > >-Fedora Patent Encumbered (better name) aka > > Debian non-US > >-Fedora Non Commercial > >-Fedora Non Free > > > > > We would also need > -Fedora for Non-Lawyers > > for ordinary users. How is one supposed to figure out where to > look for > things, and what all these repositories mean? This should be > kept simple. > > Is there a way of including proprietary drivers with the Fedora > Project? In time, Nvidia, ATI et al will definitely have the best > available linux drivers for their hardware so it seems inevitable that > proprietary drivers will have to be included in Fedora. > > They're giving away their drivers for free anyways. No and on what do you base that statement, I find the best driver currently to be the ATI r200 driver in the X.org tree and I would contest that the OGC driver has potential to be another fine driver when the card is delivered. - David -- Obligatory shameless blog plug - the GNOME commentary located at: www.lovesunix.net/blog From nicolas.mailhot at laposte.net Wed Feb 22 10:55:25 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 22 Feb 2006 11:55:25 +0100 (CET) Subject: Multiple concurrent versions of Python In-Reply-To: References: Message-ID: <48385.192.54.193.25.1140605725.squirrel@rousalka.dyndns.org> Le Mer 22 f?vrier 2006 11:05, Aurelien Bompard a ?crit : Hi, > The solution discussed with the Zope dev would be to ship python 2.3.5. > There is a way to ship both versions, using the "alternatives" system > (like > sendmail and postfix). The symlink would be on /usr/bin/python > and /usr/bin/python2. Well, you know Fedora is python oriented but its stated aim is rapid tech advancement. So if any Fedora effort is to be expended making zope/plone work it should be aimed at accelerating the porting not creating yet another reason to stall it (Yes Debian does it another way. Have you noticed Debian lifecycles too ?) And I understand this is not a comfortable position. But in IT confort leads to sclerosis. Regards, -- Nicolas Mailhot From arjan at fenrus.demon.nl Wed Feb 22 10:56:17 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Wed, 22 Feb 2006 11:56:17 +0100 Subject: Non-free Extras? In-Reply-To: References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> <43FC1F67.7080607@argo.co.il> Message-ID: <1140605778.2979.12.camel@laptopd505.fenrus.org> On Wed, 2006-02-22 at 05:03 -0500, Benjy Grogan wrote: > > > On 2/22/06, Avi Kivity wrote: > Goede, J.W.R. de wrote: > > >Talking about solutions and not problems I propose: > >-Fedora Extras (as is) > >-Fedora Patent Encumbered (better name) aka > > Debian non-US > >-Fedora Non Commercial > >-Fedora Non Free > > > > > We would also need > -Fedora for Non-Lawyers > > for ordinary users. How is one supposed to figure out where to > look for > things, and what all these repositories mean? This should be > kept simple. > > Is there a way of including proprietary drivers with the Fedora > Project? since these drivers are rather "shakey" with respect to copyright law (which is different than the traditional "US Patents" reason for not including things) I would say "No." In fact just about all other distros don't do these drivers either, or not anymore..... From alan at redhat.com Wed Feb 22 11:42:05 2006 From: alan at redhat.com (Alan Cox) Date: Wed, 22 Feb 2006 06:42:05 -0500 Subject: The future of Linux - architecture and package In-Reply-To: <1140558444.13224.2.camel@rousalka.dyndns.org> References: <20060221141944.GA25869@devserv.devel.redhat.com> <20060221165534.GA10234@devserv.devel.redhat.com> <1140545472.12119.1.camel@rousalka.dyndns.org> <20060221182037.GA17897@devserv.devel.redhat.com> <1140558444.13224.2.camel@rousalka.dyndns.org> Message-ID: <20060222114205.GA20029@devserv.devel.redhat.com> On Tue, Feb 21, 2006 at 10:47:24PM +0100, Nicolas Mailhot wrote: > Waiting Shelter R001 seems to render and print fine with rawhide evince > (apart from the usual "all the world is a Letter printer - let's f*-up > A4 borders" Gnome print bug) Is the graffiti on a black background or on texture that is where the previous one I tried broke - it should be on texture From gauret at free.fr Wed Feb 22 12:05:56 2006 From: gauret at free.fr (Aurelien Bompard) Date: Wed, 22 Feb 2006 13:05:56 +0100 Subject: Multiple concurrent versions of Python References: <48385.192.54.193.25.1140605725.squirrel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot wrote: > So if any Fedora effort is to be expended making zope/plone > work it should be aimed at accelerating the porting not creating yet > another reason to stall it Agreed, that would be the Right Way. But as a packager, will this happen ? Do we have among the Fedora devs someone who will make sure Zope works with the version of python Fedora ships ? Otherwise, Zope will remain unsupported on Fedora, which is a pity. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin From alan at redhat.com Wed Feb 22 12:06:30 2006 From: alan at redhat.com (Alan Cox) Date: Wed, 22 Feb 2006 07:06:30 -0500 Subject: Non-free Extras? In-Reply-To: References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> <43FC1F67.7080607@argo.co.il> Message-ID: <20060222120630.GD20029@devserv.devel.redhat.com> On Wed, Feb 22, 2006 at 05:03:52AM -0500, Benjy Grogan wrote: > Is there a way of including proprietary drivers with the Fedora Project? In > time, Nvidia, ATI et al will definitely have the best available linux > drivers for their hardware so it seems inevitable that proprietary drivers > will have to be included in Fedora. Fedora is free software. If you want to add proprietary software whether that is Nvidia drivers, Oracle or Quake 4 then its between you and the vendor. The Nvidia and Ati drivers are actually more tricky than the proprietary applications to deal with because their legality is open to some dispute. > They're giving away their drivers for free anyways. Only in price, and then you pay a terrible price if you want to debug anything or your system isn't stable Alan From ndbecker2 at gmail.com Wed Feb 22 12:06:45 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 22 Feb 2006 07:06:45 -0500 Subject: libstdc++-so7 info? Message-ID: I noticed the libstdc++-so7 preview, but I haven't been able to find any information that summarizes what is new, compared with the current libstdc++. Any pointers? From jakub at redhat.com Wed Feb 22 12:09:33 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 22 Feb 2006 07:09:33 -0500 Subject: libstdc++-so7 info? In-Reply-To: References: Message-ID: <20060222120933.GZ24295@devserv.devel.redhat.com> On Wed, Feb 22, 2006 at 07:06:45AM -0500, Neal Becker wrote: > I noticed the libstdc++-so7 preview, but I haven't been able to find any > information that summarizes what is new, compared with the current > libstdc++. Any pointers? It is only included for scim purposes, please don't use it for anything else. It contains various ABI breaking experimental STL changes that are not applicable to libstdc++.so.6. Jakub From nicolas.mailhot at laposte.net Wed Feb 22 12:15:51 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 22 Feb 2006 13:15:51 +0100 (CET) Subject: The future of Linux - architecture and package In-Reply-To: <20060222114205.GA20029@devserv.devel.redhat.com> References: <20060221141944.GA25869@devserv.devel.redhat.com> <20060221165534.GA10234@devserv.devel.redhat.com> <1140545472.12119.1.camel@rousalka.dyndns.org> <20060221182037.GA17897@devserv.devel.redhat.com> <1140558444.13224.2.camel@rousalka.dyndns.org> <20060222114205.GA20029@devserv.devel.redhat.com> Message-ID: <7176.192.54.193.25.1140610551.squirrel@rousalka.dyndns.org> Le Mer 22 f?vrier 2006 12:42, Alan Cox a ?crit : > On Tue, Feb 21, 2006 at 10:47:24PM +0100, Nicolas Mailhot wrote: >> Waiting Shelter R001 seems to render and print fine with rawhide evince >> (apart from the usual "all the world is a Letter printer - let's f*-up >> A4 borders" Gnome print bug) > > Is the graffiti on a black background or on texture that is where the > previous one I tried broke - it should be on texture I'll check this evening -- Nicolas Mailhot From jfrieben at freesurf.fr Wed Feb 22 12:28:54 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Wed, 22 Feb 2006 13:28:54 +0100 (CET) Subject: Low OpenGL performance Message-ID: <36006.194.94.224.254.1140611334.squirrel@jose.freesurf.fr> After installing FC5T3 including updates on 2 different machines, I am puzzled by the surprisingly poor OpenGL performance when running the "glxgears" command: IBM ThinkPad T23 [SuperSavage IX/C SDR]: 115 FPS when other users report values of at least 240 FPS. Similarly for a PR440FX based SPM system [Radon 7200 PCI]: 160 FPS when I used to achieve 360 FPS for earlier releases. In both cases, "DRI" is enabled. "LIBGL_DEBUG" is set to "verbose", and "glxinfo" output looks ok. Moreover, I booted with "enforcing=0" to avoid any "SELinux" trouble ... . Any ideas? Similar observations? From ivg2 at cornell.edu Wed Feb 22 12:33:31 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Wed, 22 Feb 2006 07:33:31 -0500 Subject: Non-free Extras? In-Reply-To: <20060222120630.GD20029@devserv.devel.redhat.com> References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> <43FC1F67.7080607@argo.co.il> <20060222120630.GD20029@devserv.devel.redhat.com> Message-ID: <43FC5A1B.4070106@cornell.edu> >> They're giving away their drivers for free anyways. >> > > Only in price, and then you pay a terrible price if you want to debug anything > or your system isn't stable > > Right... but since I don't want the debug anything, and my system is stable, I don't pay a terrible price. [if (false) => x] is true. The system could destabilize in the future, at which point I'll re-evaluate my use of Nvidia cards. Speaking of which, the nv driver is rather unstable, and does not work for me at the moment - just filed a bug... For the moment I haven't heard of an OSS solution with good performance for 3D games.... or wireless drivers for atheros. Since 3D games and wireless drivers are rather important to me, I accept reality and use what's available. Surely my hardware working with proprietary drivers is better than my hardware not working at all. I see no problem with using the livna repository, so I'm not sure what this thread's all about. What would be useful is: - development branch of the livna repository (it's constantly out-of-sync for rawhide testers!) - some sort of ABI, so that modules don't have to be recompiled for each and every kernel (wasn't something like this under development in the 2.6 cycle? arguments against it never made any sense to me) From naoki at valuecommerce.com Wed Feb 22 12:39:21 2006 From: naoki at valuecommerce.com (Naoki) Date: Wed, 22 Feb 2006 21:39:21 +0900 Subject: Low OpenGL performance In-Reply-To: <36006.194.94.224.254.1140611334.squirrel@jose.freesurf.fr> References: <36006.194.94.224.254.1140611334.squirrel@jose.freesurf.fr> Message-ID: <1140611961.2384.226.camel@dragon.sys.intra> I get 160/170 on nvidia [Quadro4 NVS AGP 8x]. Standard "nv" driver, no nvidia driver. On Wed, 2006-02-22 at 13:28 +0100, Joachim Frieben wrote: > After installing FC5T3 including updates on 2 different machines, I am > puzzled by the surprisingly poor OpenGL performance when running the > "glxgears" command: > > IBM ThinkPad T23 [SuperSavage IX/C SDR]: 115 FPS > > when other users report values of at least 240 FPS. Similarly for a > > PR440FX based SPM system [Radon 7200 PCI]: 160 FPS > > when I used to achieve 360 FPS for earlier releases. In both cases, "DRI" is > enabled. "LIBGL_DEBUG" is set to "verbose", and "glxinfo" output looks ok. > Moreover, I booted with "enforcing=0" to avoid any "SELinux" trouble ... . From nicolas.mailhot at laposte.net Wed Feb 22 12:44:18 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 22 Feb 2006 13:44:18 +0100 (CET) Subject: Multiple concurrent versions of Python In-Reply-To: References: <48385.192.54.193.25.1140605725.squirrel@rousalka.dyndns.org> Message-ID: <10428.192.54.193.25.1140612258.squirrel@rousalka.dyndns.org> Le Mer 22 f?vrier 2006 13:05, Aurelien Bompard a ?crit : > Nicolas Mailhot wrote: >> So if any Fedora effort is to be expended making zope/plone >> work it should be aimed at accelerating the porting not creating yet >> another reason to stall it > > Agreed, that would be the Right Way. But as a packager, will this happen ? > Do we have among the Fedora devs someone who will make sure Zope works > with > the version of python Fedora ships ? > Otherwise, Zope will remain unsupported on Fedora, which is a pity. You won't get multiple python installs without efforts at the Fedora Core level anyway, so the issue is in Red Hat's hands. (What makes me mad is the Zope/plone folks "discovering" FC5 python at the FC5T3 time - it's not as is the Fedora schedule was not public. This is as bad as what closed software folks do. More coordination with upstream wouldn't hurt) -- Nicolas Mailhot From dedourek at unb.ca Wed Feb 22 13:35:24 2006 From: dedourek at unb.ca (John DeDourek) Date: Wed, 22 Feb 2006 09:35:24 -0400 Subject: closing older bug reports without looking = bad practice ? In-Reply-To: <43FC10F5.6090206@mharris.ca> References: <1140463650.3252.30.camel@mariusa-ro.ro.oracle.com> <43FC10F5.6090206@mharris.ca> Message-ID: <43FC689C.2020105@unb.ca> Just to add one thought. There is some additional manpower out here, but.... As the linux "system" has grown more complex, the gap in knowledge between the developers and the users has grown. Consider a bug troubling me at the moment: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163417 Bug 163417 basically says that the required /dev/hdd4 device node for an IDE/ATAPI ZIP drive is not being created automatically, resulting in some difficulty mounting the drive. I can spend "some" time on better identifying the cause of this drive. I have "some" background in the technologies to debug such a problem. I made a search for documentation which would outline the general way the kernel/driver/udev/ hal/ etc. system should work. Found lots of stuff on why udev was good. But nothing that said overall, architecturally, this is the way nodes should get created for partitions for a "removable floppy" with partitions. Unfortunately, my "some background" is not sufficient to "read the source". My thought is that a little tradeoff between development and documentation time (a little more of the latter) would result in a greater pool of people providing useful information that more quickly resolves some of the bugs troubling the linux system. Just my own thought. From jfrieben at freesurf.fr Wed Feb 22 13:57:42 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Wed, 22 Feb 2006 14:57:42 +0100 (CET) Subject: Low OpenGL performance In-Reply-To: <1140611961.2384.226.camel@dragon.sys.intra> References: <1140611961.2384.226.camel@dragon.sys.intra> Message-ID: <48537.194.94.224.254.1140616662.squirrel@arlette.freesurf.fr> Yes, for the "nv" driver, you do not obtain any hardware acceleration at all. So, the values are still reasonable for pure soft rendering and equivalent for my own older hardware with "DRI" enabled! > I get 160/170 on nvidia [Quadro4 NVS AGP 8x]. Standard "nv" driver, no > nvidia driver. From pertusus at free.fr Wed Feb 22 14:00:44 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 22 Feb 2006 15:00:44 +0100 Subject: Results for install and remove tests for FC-Devel In-Reply-To: <43FC3ECA.9020100@redhat.com> References: <43FC3ECA.9020100@redhat.com> Message-ID: <20060222140044.GA2959@free.fr> > 93 failures because of missing PreReq: coreutils (various commands in > scripts not available during install or erase) I may be completely wrong, but couldn't it be assumed that coreutils is always installed? A linux system without rm doesn't make much sense... -- Pat From pjones at redhat.com Wed Feb 22 14:18:33 2006 From: pjones at redhat.com (Peter Jones) Date: Wed, 22 Feb 2006 09:18:33 -0500 Subject: FC5 test3 -- dmraid broken? In-Reply-To: <1140587745.3551.20.camel@mentorng.gurulabs.com> References: <1140499892.3430.13.camel@mentorng.gurulabs.com> <1140536181.20618.2.camel@localhost.localdomain> <1140587745.3551.20.camel@mentorng.gurulabs.com> Message-ID: <1140617913.22131.5.camel@localhost.localdomain> On Tue, 2006-02-21 at 22:55 -0700, Dax Kelson wrote: > I added echos such as "about to dm create" and then some "sleep 5" after > each of those commands. > > There is zero output from mkdmnod on down until the "lvm vgscan" runs. Well, that means nothing thinks it's not working. Not an encouraging sign :/ > It produces this output: > > device-mapper: 4.5.0-ioctl (2005-10-04) initialised: dm-devel at redhat.com > Reading all physical volumes. This may take a while... > No volume groups found > Unable to find volume group "VolGroup00" > ... > > Booting into the rescue environment the dm raid is brought up and LVM > activated automatically and correctly. Hrm. If you run "dmsetup table" from this environment, does the output match the "dm create" line in the initrd? It's almost as if lvm isn't checking the dm volumes, but that shouldn't be the case with even remotely recent lvm2. > Incidentally in the rescue environment I chrooted into my rootfilesytem > and brought up my network interface (/etc/init.d/network start), and ran > yum -y update. > > There were about 40 packages downloaded, but every rpm install attempt > puked out out with errors from the preinstall scripts. Unsurprisingly > running rpm -Uvh /path/to/yum/cache/kernel*rpm resulted in the same > error. :( This could be related, but my gut reaction says it's not caused by your raid problems. Obviously it's still bad. -- Peter From fedora at camperquake.de Wed Feb 22 14:32:44 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 22 Feb 2006 15:32:44 +0100 Subject: Hotplug: no more fstab entries Message-ID: <20060222153244.002ea18c@dhcp05.addix.net> Hi. For some time now plugging in a new device does not create an entry in /etc/fstab any more. The device shows up in nautilus just fine and can be mounted and unmounted. Working from the command line is quite a hassle, though (just like in pre-udev-days). Is this intentional? From tbrinkman at sbcglobal.net Wed Feb 22 14:46:16 2006 From: tbrinkman at sbcglobal.net (Tom Brinkman) Date: Wed, 22 Feb 2006 09:46:16 -0500 Subject: Low OpenGL performance In-Reply-To: <48537.194.94.224.254.1140616662.squirrel@arlette.freesurf.fr> References: <1140611961.2384.226.camel@dragon.sys.intra> <48537.194.94.224.254.1140616662.squirrel@arlette.freesurf.fr> Message-ID: <200602220946.16075.tbrinkman@sbcglobal.net> On Wednesday 22 February 2006 08:57, Joachim Frieben wrote: > Yes, for the "nv" driver, you do not obtain any hardware > acceleration at all. Not quite true, an hasn't been for several years. What you don't have with 'nv' is direct rendering (DRI). Needed for 3d/accel games. Prior to SGI's contributions a few years ago, 'glxgears' wouldn't even run at all. (from glxinfo) display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 > So, the values are still reasonable for pure > soft rendering and equivalent for my own older hardware with "DRI" > enabled! > > > I get 160/170 on nvidia [Quadro4 NVS AGP 8x]. Standard "nv" > > driver, no nvidia driver. GeF4, nv driver, Athlon XP 3200+/400.. 380 / 390fps on the small default window, but when run full screen, 1280x1024-24 it drops to 27 / 30fps. -- Tom Brinkman Corpus Christi, Texas From seanlkml at sympatico.ca Wed Feb 22 14:11:13 2006 From: seanlkml at sympatico.ca (sean) Date: Wed, 22 Feb 2006 09:11:13 -0500 Subject: closing older bug reports without looking = bad practice ? In-Reply-To: <43FC689C.2020105@unb.ca> References: <1140463650.3252.30.camel@mariusa-ro.ro.oracle.com> <43FC10F5.6090206@mharris.ca> <43FC689C.2020105@unb.ca> Message-ID: On Wed, 22 Feb 2006 09:35:24 -0400 John DeDourek wrote: > Consider a bug troubling me at the moment: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163417 > Bug 163417 basically says that the required /dev/hdd4 device > node for an IDE/ATAPI ZIP drive is not being created > automatically, resulting in some difficulty mounting the drive. > Check out: http://fedora.redhat.com/docs/udev/ There is an upstream mailing list mentioned that should be a good resource to ask any questions not answered by the current documentation. Sean From jamatos at fc.up.pt Wed Feb 22 15:04:07 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Wed, 22 Feb 2006 15:04:07 +0000 Subject: Results for install and remove tests for FC-Devel In-Reply-To: <20060222140044.GA2959@free.fr> References: <43FC3ECA.9020100@redhat.com> <20060222140044.GA2959@free.fr> Message-ID: <200602221504.07448.jamatos@fc.up.pt> On Wednesday 22 February 2006 14:00, Patrice Dumas wrote: > > 93 failures because of missing PreReq: coreutils (various commands in > > scripts not available during install or erase) > > I may be completely wrong, but couldn't it be assumed that > coreutils is always installed? A linux system without rm doesn't > make much sense... For Extras, at least, coreutils is listed as one of the exceptions to the BuildRequires rule: http://fedoraproject.org/wiki/Packaging/Guidelines#head-4cadce5e79d38a63cad3941de1dadc9d25d67d30 > -- > Pat -- Jos? Ab?lio From mitr at volny.cz Wed Feb 22 15:06:42 2006 From: mitr at volny.cz (Miloslav Trmac) Date: Wed, 22 Feb 2006 16:06:42 +0100 Subject: Results for install and remove tests for FC-Devel In-Reply-To: <20060222140044.GA2959@free.fr> References: <43FC3ECA.9020100@redhat.com> <20060222140044.GA2959@free.fr> Message-ID: <43FC7E02.1000705@volny.cz> Patrice Dumas napsal(a): > I may be completely wrong, but couldn't it be assumed that > coreutils is always installed? A linux system without rm doesn't > make much sense... Not during installation :) anaconda uses package dependencies to order the package installation correctly. Mirek From jfrieben at freesurf.fr Wed Feb 22 15:07:18 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Wed, 22 Feb 2006 16:07:18 +0100 (CET) Subject: Low OpenGL performance In-Reply-To: <200602220946.16075.tbrinkman@sbcglobal.net> References: <200602220946.16075.tbrinkman@sbcglobal.net> Message-ID: <61699.194.94.224.254.1140620838.squirrel@arlette.freesurf.fr> Given that the subject of my post was "Low OpenGL performance", I was obviously only talking about (3D) direct rendering. Typing "man nv" allows you to learn immediately that 2D acceleration is of course available. We are not in the 80ies anymore. Anyway, thanks for posting your FPS. I am very interested in results by other "T23" users. My current results ("DRI" *is* enabled as "env LIBGL_DEBUG=verbose glxinfo" says .. "direct rendering: Yes" .. and no complaints that it cannot load "savage_dri.so" and the like). I checked with a current "Ubuntu" live CD. Not terrific either, but about 200 FPS is still better than 115 FPS which I achieve with FC5T3. > On Wednesday 22 February 2006 08:57, Joachim Frieben wrote: >> Yes, for the "nv" driver, you do not obtain any hardware >> acceleration at all. > > Not quite true, an hasn't been for several years. What you don't > have with 'nv' is direct rendering (DRI). Needed for 3d/accel games. From buildsys at redhat.com Wed Feb 22 15:22:47 2006 From: buildsys at redhat.com (Build System) Date: Wed, 22 Feb 2006 10:22:47 -0500 Subject: rawhide report: 20060222 changes Message-ID: <200602221522.k1MFMlVf027874@porkchop.devel.redhat.com> Updated Packages: NetworkManager-0.5.1-13.cvs20060221 ----------------------------------- * Tue Feb 21 2006 Dan Williams 0.5.1-13.cvs20060221 - Add BuildRequires: libnl-devel (#rh179438#) - Fix libnm_glib to not clobber an application's existing dbus connection (#rh177546#, gnome.org #326572) - libnotify support - AP compatibility fixes anaconda-10.92.7-1 ------------------ * Tue Feb 21 2006 Chris Lumens 10.92.7-1 - Give Language a default display_mode (dcantrel) - Get languages that need a default from localeInfo (dcantrel) * Tue Feb 21 2006 Chris Lumens 10.92.6-1 - Set a default language on text mode CJK installs (dcantrel, #180417) - Fix case-sensitive matching of devices (notting, #182231) - Be smarter about required media (pnasrat) - Set MTU in the loader (katzj) - Add dev package to remove blacklist (katzj, #181593) - Try to mount device as ext3 in hard drive installs (katzj) - Sanity check unknown package & group names (pnasrat) - Reboot after writing exception dump (#181745) - Confirm in interactive kickstart installs (#181741) - Fix showing kickstart package selection again - Don't traceback if we find a %include file that doesn't exist yet (#181760) - Skip partitioning if logvol or raid is given in ks (#181806) - Initialize UTC checkbox (#181737) beagle-0.2.1-8 -------------- * Tue Feb 21 2006 Matthias Clasen 0.2.1-8 - Autostart beagled by default - Use anacron - Install the firefox extension - Add a trigger to reinstall the firefox extension on firefox updates - Adapt crawl-rules to Fedora * Fri Feb 17 2006 Karsten Hopp 0.2.1-7 - add BuildRequires checkpolicy-1.29.4-1 -------------------- * Thu Feb 16 2006 Dan Walsh - 1.29.4-1 - Latest upgrade from NSA * Added a check for failure to declare each sensitivity in a level definition. * Changed to clone level data for aliased sensitivities to avoid double free upon sens_destroy. Bug reported by Kevin Carr of Tresys Technology. cryptsetup-luks-1.0.1-5 ----------------------- * Mon Feb 20 2006 Karsten Hopp 1.0.1-5 - BuildRequires: libselinux-devel dhcp-11:3.0.3-24 ---------------- * Mon Feb 20 2006 Jason Vas Dias - 11:3.0.3-24 - Apply upstream fix for bug 176615 / ISC RT#15811 gnome-doc-utils-0.5.6-1 ----------------------- * Mon Feb 20 2006 Matthias Clasen - 0.5.6-1 - Update to 0.5.6 gnome-user-docs-2.13.1.1-1 -------------------------- * Tue Feb 21 2006 Matthias Clasen 2.13.1.1-1 - Update to 2.13.1.1 kdebase-6:3.5.1-5 ----------------- * Tue Feb 21 2006 Than Ngo 6:3.5.1-5 - fixed rpm file conflict - added missing Category X-KDE-LookNFeel * Thu Feb 16 2006 Than Ngo 6:3.5.1-4 - Systray icons not docked sometimes, apply patch to fix this issue #180314 * Wed Feb 15 2006 Than Ngo 6:3.5.1-3 - kscreensaver/kdm/kcheckpass use a separate PAM config file #66902 - cleanup kdm config file #166388 - apply patch to launch kde scripts in shutdown,env directories #178326 - kdm.log logrotate-enabled #178328 - add konqueror webshortcuts for fedora project #178366 - don't include unnecessary README #169331 kdegraphics-7:3.5.1-3 --------------------- * Thu Feb 16 2006 Than Ngo 7:3.5.1-3 - apply patch to fix kpdf build with modular-X again #173836 kdelibs-6:3.5.1-2.3 ------------------- * Tue Feb 21 2006 Than Ngo 6:3.5.1-2.3 - apply patch to fix missing icons in KDE main menu - requires redhat-artwork >= 0.239-2 - don't own /usr/share/icons/hicolor #178319 - remove broken links #154093 kernel-2.6.15-1.1975_FC5 ------------------------ * Tue Feb 21 2006 Dave Jones - 2.6.16rc4-git2 - Make some more UP x86-64s able to boot an SMP kernel by forcing the number of CPUs to at least 1. - default fat filesystems to use UTF-8 * Tue Feb 21 2006 Rik van Riel - Make it possible to disable xen and kdump builds. - Add Xen cpu steal accounting code. * Mon Feb 20 2006 Dave Jones - Fix incorrect hardlink count in selinuxfs (#182001) kudzu-1.2.31-1 -------------- * Tue Feb 21 2006 Bill Nottingham - 1.2.31-1 - further x86emu-related fixes (#181467) libXvMC-1.0.1-3 --------------- * Tue Feb 21 2006 Mike A. Harris 1.0.1-3 - Added libXvMC-1.0.1-libXvMC-XConfigDir-fix-bug180902.patch to fix (#180902) libsemanage-1.5.28-1 -------------------- * Fri Feb 17 2006 Dan Walsh - 1.5.28-1 - Upgrade to latest from NSA * Merged bug fix for fcontext validate handler from Ivan Gyurdiev. * Merged base_merge_components changes from Ivan Gyurdiev. * Thu Feb 16 2006 Dan Walsh - 1.5.26-1 - Upgrade to latest from NSA * Merged paths array patch from Ivan Gyurdiev. * Merged bug fix patch from Ivan Gyurdiev. * Merged improve bindings patch from Ivan Gyurdiev. * Merged use PyList patch from Ivan Gyurdiev. * Merged memory leak fix patch from Ivan Gyurdiev. * Merged nodecon support patch from Ivan Gyurdiev. * Merged cleanups patch from Ivan Gyurdiev. * Merged split swig patch from Ivan Gyurdiev. libsepol-1.11.18-2 ------------------ * Mon Feb 20 2006 Dan Walsh 1.11.18-2 - Rebuild for fc5-head * Fri Feb 17 2006 Dan Walsh 1.11.18-1 - Upgrade to latest from NSA * Merged node_expand_addr bugfix and node_compare* change from Ivan Gyurdiev. * Thu Feb 16 2006 Dan Walsh 1.11.17-1 - Upgrade to latest from NSA * Merged nodes, ports: always prepend patch from Ivan Gyurdiev. * Merged bug fix patch from Ivan Gyurdiev. * Added a defined flag to level_datum_t for use by checkpolicy. * Merged nodecon support patch from Ivan Gyurdiev. * Merged cleanups patch from Ivan Gyurdiev. libuser-0.54.5-1 ---------------- * Tue Feb 21 2006 Miloslav Trmac - 0.54.5-1 - Fix multilib conflict on libuser.conf.5 openssh-4.3p2-2 --------------- * Tue Feb 21 2006 Tomas Mraz - 4.3p2-2 - print error from scp if not remote (patch by Bjorn Augustsson #178923) pirut-0.9.13-1 -------------- * Wed Feb 22 2006 Jeremy Katz - 0.9.13-1 - add files * Tue Feb 21 2006 Jeremy Katz - 0.9.12-1 - enable search functionality * Tue Feb 21 2006 Jeremy Katz - 0.9.11-1 - Don't try to install source packages (#180048) - Fix wrong error name (#181370) - Ensure group is selected for select all - Log installs from all tools in yum.log (#182126) - Don't traceback on servers not telling us the size (#181890) - Start of work for search to work - Add some details about what's selected for install/remove (#182126) policycoreutils-1.29.26-1 ------------------------- * Mon Feb 13 2006 Dan Walsh 1.29.26-1 - Update from upstream * Merged semanage bug fix patch from Ivan Gyurdiev. * Merged improve bindings patch from Ivan Gyurdiev. * Merged semanage usage patch from Ivan Gyurdiev. * Merged use PyList patch from Ivan Gyurdiev. pykickstart-0.21-1 ------------------ * Fri Feb 17 2006 Chris Lumens 0.21-1 - Provide an option to not traceback on missing include files (#181760). - Update programming documentation. redhat-artwork-0.239-2 ---------------------- * Tue Feb 21 2006 Than Ngo 0.239-2 - link KDE upstream icon names to the redhat ones in bluecurve selinux-policy-2.2.19-2 ----------------------- * Tue Feb 21 2006 Dan Walsh 2.2.19-2 - Fix swapon - allow httpd_sys_script_t to be entered via a shell - Allow httpd_sys_script_t to read eventpolfs * Tue Feb 21 2006 Dan Walsh 2.2.19-1 - Update from upstream * Tue Feb 21 2006 Dan Walsh 2.2.18-2 - allow cron to read apache files xorg-x11-drv-ati-6.5.7.3-4 -------------------------- * Tue Feb 21 2006 Mike A. Harris 6.5.7.3-4 - Added xorg-x11-drv-ati-6.5.7.3-radeon-metamodes-SEGV-fix.patch from CVS HEAD. xorg-x11-font-utils-1:1.0.1-2 ----------------------------- * Fri Feb 17 2006 Mike A. Harris 1:1.0.1-2 - Added with_X11R6_compat macro to conditionalize inclusion of mkfontdir and mkfontscale symlinks in the old X11R6 locations, pointing to the X11R7 binaries. This will provide backward compatibilty for Fedora Core 5, however 3rd party developers and rpm package maintainers should update to using the new X11R7 locations immediately, as these compatibility links are temporary, and will be removed from a future OS release. - Remove system directories from file manifest to appease the banshees. * Fri Feb 10 2006 Jesse Keating 1:1.0.1-1.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating 1:1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-xinit-1.0.1-2 ---------------------- * Thu Feb 16 2006 Mike A. Harris 1.0.1-2 - Change Conflicts to Obsoletes for xorg-x11 and XFree86 (#181414) xorg-x11-xkbdata-1.0.1-3 ------------------------ * Tue Feb 21 2006 Mike A. Harris 1.0.1-3 - Added xkbdata-1.0.1-greek-fix-bug181313.patch to fix (#181313,181313) - Added xkbdata-1.0.1-cz-fix-bug177362.patch to fix (#177362,178892) yaboot-1.3.13-0.18 ------------------ * Tue Feb 21 2006 Paul Nasrat - 1.3.13-0.18 - Drop telnet console patch for now (#182180) Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15-5.FC5.4.i686 requires kernel = 0:2.6.15-1.1955_FC5 GFS-kernel - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5 GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5smp cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp gnbd-kernel - 2.6.15-5.FC5.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs vconfig - 1.9-1.1.ia64 requires libc.so.6 vconfig - 1.9-1.1.ia64 requires libc.so.6(GLIBC_2.0) Broken deps for ppc64 ---------------------------------------------------------- emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi vconfig - 1.9-1.1.ppc64 requires libc.so.6 vconfig - 1.9-1.1.ppc64 requires libc.so.6(GLIBC_2.0) Broken deps for s390 ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 Broken deps for s390x ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 From pknirsch at redhat.com Wed Feb 22 15:25:31 2006 From: pknirsch at redhat.com (Phil Knirsch) Date: Wed, 22 Feb 2006 16:25:31 +0100 Subject: Results for install and remove tests for FC-Devel In-Reply-To: <200602221504.07448.jamatos@fc.up.pt> References: <43FC3ECA.9020100@redhat.com> <20060222140044.GA2959@free.fr> <200602221504.07448.jamatos@fc.up.pt> Message-ID: <43FC826B.3000109@redhat.com> Jose' Matos wrote: > On Wednesday 22 February 2006 14:00, Patrice Dumas wrote: >>> 93 failures because of missing PreReq: coreutils (various commands in >>> scripts not available during install or erase) >> I may be completely wrong, but couldn't it be assumed that >> coreutils is always installed? A linux system without rm doesn't >> make much sense... > > For Extras, at least, coreutils is listed as one of the exceptions to the > BuildRequires rule: > > http://fedoraproject.org/wiki/Packaging/Guidelines#head-4cadce5e79d38a63cad3941de1dadc9d25d67d30 > Those only speaks about BuildRequires though, and there i completely agree that a certain base set of development packages has to be installed before trying to rebuild anything. What my test covered though is install and remove requirements (resp. PreReqs to be more precise) and without that information rpm can't determine wether it needs to install coreutils before or after some package. 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 pknirsch at redhat.com Wed Feb 22 15:26:20 2006 From: pknirsch at redhat.com (Phil Knirsch) Date: Wed, 22 Feb 2006 16:26:20 +0100 Subject: Results for install and remove tests for FC-Devel In-Reply-To: <43FC7E02.1000705@volny.cz> References: <43FC3ECA.9020100@redhat.com> <20060222140044.GA2959@free.fr> <43FC7E02.1000705@volny.cz> Message-ID: <43FC829C.2060502@redhat.com> Miloslav Trmac wrote: > Patrice Dumas napsal(a): >> I may be completely wrong, but couldn't it be assumed that >> coreutils is always installed? A linux system without rm doesn't >> make much sense... > Not during installation :) anaconda uses package dependencies to order > the package installation correctly. > Mirek > Yeah, i forgot to mention, this whole test is mainly for completeness. Quite a few packages have coreutils as a requirement in Fedora Core, and for packages that have a real PreReq this actually makes sense and is certainly needed as rpm otherwise could always just put coreutils at some later point in the install order and suddenly tons of pre or post install scripts would break. And thats basically what this test revealed, that there are actually quite a few packages that can break if coreutils isn't installed prior to them, so this is really a missing PreReq dependency. 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 rdieter at math.unl.edu Wed Feb 22 15:41:44 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 22 Feb 2006 09:41:44 -0600 Subject: Results for install and remove tests for FC-Devel In-Reply-To: <43FC829C.2060502@redhat.com> References: <43FC3ECA.9020100@redhat.com> <20060222140044.GA2959@free.fr> <43FC7E02.1000705@volny.cz> <43FC829C.2060502@redhat.com> Message-ID: Phil Knirsch wrote: > there are actually quite a few packages that can break if > coreutils isn't installed prior to them, so this is really a missing > PreReq dependency. Or more precisely, they're missing at least one of Requires(post): coreutils Requiers(pre): coreutils PreReq implies also that coreutils is required after-install/at-runtime, which may or may not be true. -- Rex From pertusus at free.fr Wed Feb 22 15:54:24 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 22 Feb 2006 16:54:24 +0100 Subject: Results for install and remove tests for FC-Devel In-Reply-To: <43FC829C.2060502@redhat.com> References: <43FC3ECA.9020100@redhat.com> <20060222140044.GA2959@free.fr> <43FC7E02.1000705@volny.cz> <43FC829C.2060502@redhat.com> Message-ID: <20060222155424.GB2959@free.fr> > Yeah, i forgot to mention, this whole test is mainly for completeness. > Quite a few packages have coreutils as a requirement in Fedora Core, and > for packages that have a real PreReq this actually makes sense and is > certainly needed as rpm otherwise could always just put coreutils at > some later point in the install order and suddenly tons of pre or post > install scripts would break. And thats basically what this test > revealed, that there are actually quite a few packages that can break if > coreutils isn't installed prior to them, so this is really a missing > PreReq dependency. Thanks for the explanation... Indeed it isn't a live system but a filesystem being populated at the same time scripts are run, so having coreutils required is indeed important. Maybe, when the filesystem is depopulated coreutils cannot be removed anyway but who knows, it is indeed still a good thing to have everything right. I don't know if it is easy/possible/interesting, but if it is, could it be possible to do similar things for extras without too much work? Or maybe it is too early as extras are not handled by anaconda anyway? -- Pat From gauret at free.fr Wed Feb 22 15:56:53 2006 From: gauret at free.fr (Aurelien Bompard) Date: Wed, 22 Feb 2006 16:56:53 +0100 Subject: Multiple concurrent versions of Python References: <48385.192.54.193.25.1140605725.squirrel@rousalka.dyndns.org> <10428.192.54.193.25.1140612258.squirrel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot wrote: > (What makes me mad is the Zope/plone folks "discovering" FC5 python at the > FC5T3 time - it's not as is the Fedora schedule was not public. This is as > bad as what closed software folks do. More coordination with upstream > wouldn't hurt) Actually, they've known of it for quite some time : http://www.zope.org/Products/Zope/2.8.5/Zope-2_8_5-released """ Using Python 2.4.X is not supported and not recommended at this time. Python 2.4.X will be supported when a security audit took place. This means that you are using Python 2.4 + Zope 2.8 at your own risk. This warning also applies to binary packages that install Zope packages together with a system wide Python 2.4 installation (e.g. Fedora, SuSE...). Such installations are in general not supported. In addition there some third-party products and Python packages that don't work with Python 2.4 and can cause trouble when using Python 2.4. """ They just ask people to build their own python 2.3.5 in /usr/local, and then install Zope with it. See also this bug report from Zope's release manager : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171681 Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr One OS to hook them all One browser to find them One word processor to bring them all And in monopoly, bind them... From katzj at redhat.com Wed Feb 22 16:23:06 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 22 Feb 2006 11:23:06 -0500 Subject: FC5 test3 -- dmraid broken? In-Reply-To: <1140587745.3551.20.camel@mentorng.gurulabs.com> References: <1140499892.3430.13.camel@mentorng.gurulabs.com> <1140536181.20618.2.camel@localhost.localdomain> <1140587745.3551.20.camel@mentorng.gurulabs.com> Message-ID: <1140625386.16403.0.camel@orodruin.boston.redhat.com> On Tue, 2006-02-21 at 22:55 -0700, Dax Kelson wrote: > Incidentally in the rescue environment I chrooted into my rootfilesytem > and brought up my network interface (/etc/init.d/network start), and ran > yum -y update. > > There were about 40 packages downloaded, but every rpm install attempt > puked out out with errors from the preinstall scripts. Unsurprisingly > running rpm -Uvh /path/to/yum/cache/kernel*rpm resulted in the same > error. :( This is because we haven't been mounting /selinux in the chroot. I thought someone was going to file that, but apparently it didn't happen. Went ahead and fixed in CVS Jeremy From tla-ml at rasmil.dk Wed Feb 22 16:31:22 2006 From: tla-ml at rasmil.dk (Tim Lauridsen) Date: Wed, 22 Feb 2006 17:31:22 +0100 Subject: Questioning Pirut In-Reply-To: <1140463527.2573.53.camel@bree.local.net> References: <43F6BB9D.6070703@rasmil.dk> <1140463527.2573.53.camel@bree.local.net> Message-ID: <43FC91DA.2010706@rasmil.dk> Jeremy Katz wrote: > Tim -- first off, my apologies for not getting back to your mail. > Between travel and then trying to get test releases out, I just haven't > managed to get enough time to sit down and type this up. > > On Sat, 2006-02-18 at 07:15 +0100, Tim Lauridsen wrote: > >> I have suggested to the developers to join forces and get Yum Extender >> a.k.a yumex in shape to get into Core. >> I takes time to make a good package manager gui and there are no need to >> start from scratch. >> > > It's not really starting from scratch in this case, though, as we're > leveraging a lot of the work that has had to be done for anaconda. As > with system-config-packages before it, pirut has largely been driven by > UI and other decisions made for anaconda so that we can provide a > consistent interface around software selection during and after the > installation process. > > >> The current development release of yumex 0.99.9, currently in >> extras-development, is in good shape and works in both >> FC4 and rawhide. (and in RHEL 4 (with yum 2.4.x & CentOS 4.2) >> > > I think that yumex is great and provides what a lot of people are > looking for, but at the same time, don't think that it provides the > experience that we're looking to provide as a part of the installer, etc > > Jeremy > I see it more clearly now, of cause pirut, has to look like the package selection in anaconda to make it consistent. And you are right yumex is meant be something else. What is the plans for the search feature and the repositories, what features are needed, maybe i could supply some code if i knew what features are needed. Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From katzj at redhat.com Wed Feb 22 16:32:59 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 22 Feb 2006 11:32:59 -0500 Subject: Multiple concurrent versions of Python In-Reply-To: References: Message-ID: <1140625979.16403.6.camel@orodruin.boston.redhat.com> On Wed, 2006-02-22 at 11:05 +0100, Aurelien Bompard wrote: > During the event "Solutions Linux" in Paris, I met a Zope developper who had > very good arguments on how Fedora could be improved to support more Python > applications (and Zope in particular). > > Since Fedora is rather python-oriented, and we're considering Zope for our > CMS, I think we should consider this. I maintain the Zope & Plone packages > in Extras, and I must say it's complicated, because Zope requires specific > versions of python (not the latest) and Plone requires specific versions of > Zope : I really think that this needs to be resolved by making those apps work better with more current versions of python. By that argument, what if someone wanted to build an app which was only "supported" on a 2.4 kernel -- would you argue that we should also add the infrastructure for supporting a variety of incompatible kernel versions? > The only problem is with python modules and python applications which > install files in /usr/lib/python2.4 > - python modules should be compiled for both versions of python ex: > python-imaging and python23-imaging This would hugely increase the burden on testing python modules across a variety of python versions. And the end result would be that you end up with most things not supported on the non-primary python. > - python applications installing files in /usr/lib/python2.4 should not > have #!/usr/bin/python in the shebang, but the required version : > #!/usr/bin/python2.4 and the package should require python24. The current > python rpm could Provide python24. So now to upgrade Core from one version of python to another, I have to touch every python app, even if they don't install files into python_sitelib? And not just a rebuild either, I have to make actual changes to the included scripts. Where currently, if I just rebuild with a "correct" python package, it will DTRT. Jeremy From nicolas.mailhot at laposte.net Wed Feb 22 16:35:41 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 22 Feb 2006 17:35:41 +0100 (CET) Subject: Multiple concurrent versions of Python In-Reply-To: References: <48385.192.54.193.25.1140605725.squirrel@rousalka.dyndns.org> <10428.192.54.193.25.1140612258.squirrel@rousalka.dyndns.org> Message-ID: <17264.192.54.193.25.1140626141.squirrel@rousalka.dyndns.org> Le Mer 22 f?vrier 2006 16:56, Aurelien Bompard a ?crit : > Nicolas Mailhot wrote: > >> (What makes me mad is the Zope/plone folks "discovering" FC5 python at >> the >> FC5T3 time - it's not as is the Fedora schedule was not public. This is >> as >> bad as what closed software folks do. More coordination with upstream >> wouldn't hurt) > > Actually, they've known of it for quite some time : > http://www.zope.org/Products/Zope/2.8.5/Zope-2_8_5-released ... > They just ask people to build their own python 2.3.5 in /usr/local, and > then install Zope with it. Like I wrote, this is as bad as closed software tools ;( I guess that means Zope deos not care about fedora. -- Nicolas Mailhot From dax at gurulabs.com Wed Feb 22 16:43:40 2006 From: dax at gurulabs.com (Dax Kelson) Date: Wed, 22 Feb 2006 09:43:40 -0700 Subject: FC5 test3 -- dmraid broken? In-Reply-To: <1140617913.22131.5.camel@localhost.localdomain> References: <1140499892.3430.13.camel@mentorng.gurulabs.com> <1140536181.20618.2.camel@localhost.localdomain> <1140587745.3551.20.camel@mentorng.gurulabs.com> <1140617913.22131.5.camel@localhost.localdomain> Message-ID: <1140626620.4113.9.camel@mentorng.gurulabs.com> On Wed, 2006-02-22 at 09:18 -0500, Peter Jones wrote: > On Tue, 2006-02-21 at 22:55 -0700, Dax Kelson wrote: > > > I added echos such as "about to dm create" and then some "sleep 5" after > > each of those commands. > > > > There is zero output from mkdmnod on down until the "lvm vgscan" runs. > > Well, that means nothing thinks it's not working. Not an encouraging > sign :/ It used to work when I installed rawhide last month. I guess there is no verbose mode? > > It produces this output: > > > > device-mapper: 4.5.0-ioctl (2005-10-04) initialised: dm-devel at redhat.com > > Reading all physical volumes. This may take a while... > > No volume groups found > > Unable to find volume group "VolGroup00" > > ... > > > > Booting into the rescue environment the dm raid is brought up and LVM > > activated automatically and correctly. > > Hrm. If you run "dmsetup table" from this environment, does the output > match the "dm create" line in the initrd? > > It's almost as if lvm isn't checking the dm volumes, but that shouldn't > be the case with even remotely recent lvm2. It does match. Here is the output from dmsetup table inside the rescue environment. nvidia_hcddciddp1: 0 409368267 linear 253:0 241038 nvidia_hcddcidd: 0 586114702 mirror core 2 64 nosync 2 8:16 0 8:0 0 VolGroup00-LogVol01: 0 4063232 linear 253:3 83952000 VolGroup00-LogVol00: 0 83951616 linear 253:3 384 nvidia_hcddciddp3: 0 176490090 linear 253:0 409609305 nvidia_hcddciddp2: 0 208782 linear 253:0 63 As a reference here is what is in the initramfs init file: dm create nvidia_hcddcidd 0 586114702 mirror core 2 64 nosync 2 8:16 0 8:0 0 dm partadd nvidia_hcddcidd > > Incidentally in the rescue environment I chrooted into my rootfilesytem > > and brought up my network interface (/etc/init.d/network start), and ran > > yum -y update. > > > > There were about 40 packages downloaded, but every rpm install attempt > > puked out out with errors from the preinstall scripts. Unsurprisingly > > running rpm -Uvh /path/to/yum/cache/kernel*rpm resulted in the same > > error. :( > > This could be related, but my gut reaction says it's not caused by your > raid problems. Obviously it's still bad. Indeed. And it looks like Jermey Katz just fixed that. Now if I can get control-c working and ssh/scp able to grab terminal in the rescue environment my complaints with it will be gone. Dax Kelson Guru Labs From dhollis at davehollis.com Wed Feb 22 16:42:06 2006 From: dhollis at davehollis.com (David Hollis) Date: Wed, 22 Feb 2006 11:42:06 -0500 Subject: Open Xchange for FC5 with GCJ 4.1 In-Reply-To: <1140392039.17385.390.camel@xpc.home.erwinrol.com> References: <1140392039.17385.390.camel@xpc.home.erwinrol.com> Message-ID: <1140626527.3934.24.camel@dhollis-lnx.sunera.com> On Mon, 2006-02-20 at 00:33 +0100, Erwin Rol wrote: > Of course not everything works, but database access seems to work now > with postgresql 8.1 (both server and jdbc). Webmail also seems to be > able to read mail. And I can login, so Ldap also kind of works. I think > ldap addressbook is still a problem, but that is because the ldap part > is a serious hack, the imap stuff also has some hanks. > > Since I have a busy week coming up I will continue with the development > next weekend, I hope some ppl could play around with it in the meanwhile > and report all problems to me, so I can fix them next weekend. Some initial thoughts while looking through the spec file: It would be nice to be able to keep the html docs out of /var/www/html. It may be a bit debatable as to where the best location would be, possibly /var/www/open-xchange, /usr/share/open-xchange/.... or something. Then just add a open-xchange.conf to /etc/httpd/conf.d/ that aliases the directory appropriately. Knowing how OX is, that may not be possible without totally dorking stuff up. I really don't like having to have database names, passwords, LDAP dns and such specified at build time, but I don't think OX gives any alternatives.... sigh.... Javamail - couldn't you have the OX spec depend on javamail >= 1.3.0 and have the ox_javamail.spec have a "Provides: javamail 1.3.0" or whatnot? That would allow newer javamail rpms to replace the ox_javamail when the time comes and everything can continue playing nice. You really don't have to extract the WAR files during RPM build do you? Can't you just plop the .war in the /var/lib/tomcat5/webapps dir and it will take care of everything? Though I suppose you lose the RPM owning those files... hmm, I don't know enough about tomcat app deployment to know which way is best. The gcj.patch file seems to hard code some .jars that can be specfied with configure. This could bite you later. It looks like that patch tackles a bunch of different issues, so it would be best to split it out. A lot of things might be useful to send upstream, some may be specific to getting the package to build with Fedora, etc. Check out the kernel RPMS for examples of breaking out patches. As things get merged upstream, become outdated, etc, it's very easy to remove them from the spec. You probably don't want to have to maintain a parallel source tree to generate patches. -- David Hollis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From dax at gurulabs.com Wed Feb 22 16:49:08 2006 From: dax at gurulabs.com (Dax Kelson) Date: Wed, 22 Feb 2006 09:49:08 -0700 Subject: FC5 test3 -- dmraid broken? In-Reply-To: <1140617913.22131.5.camel@localhost.localdomain> References: <1140499892.3430.13.camel@mentorng.gurulabs.com> <1140536181.20618.2.camel@localhost.localdomain> <1140587745.3551.20.camel@mentorng.gurulabs.com> <1140617913.22131.5.camel@localhost.localdomain> Message-ID: <1140626948.4113.18.camel@mentorng.gurulabs.com> On Wed, 2006-02-22 at 09:18 -0500, Peter Jones wrote: > It's almost as if lvm isn't checking the dm volumes, but that shouldn't > be the case with even remotely recent lvm2. For kicks I tried an initrd with the "rmparts" commands commented out. When I booted that I did get the expected "duplicate PV found selecting foo" messages. I rebooted before any writes could happen (I think). Dax Kelson Guru Labs From lamont at gurulabs.com Wed Feb 22 16:50:33 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Wed, 22 Feb 2006 09:50:33 -0700 Subject: Open Xchange for FC5 with GCJ 4.1 In-Reply-To: <1140626527.3934.24.camel@dhollis-lnx.sunera.com> References: <1140392039.17385.390.camel@xpc.home.erwinrol.com> <1140626527.3934.24.camel@dhollis-lnx.sunera.com> Message-ID: <200602220950.38360.lamont@gurulabs.com> On Wednesday 22 February 2006 09:42am, David Hollis wrote: > On Mon, 2006-02-20 at 00:33 +0100, Erwin Rol wrote: > > Of course not everything works, but database access seems to work now > > with postgresql 8.1 (both server and jdbc). Webmail also seems to be > > able to read mail. And I can login, so Ldap also kind of works. I think > > ldap addressbook is still a problem, but that is because the ldap part > > is a serious hack, the imap stuff also has some hanks. > > > > Since I have a busy week coming up I will continue with the development > > next weekend, I hope some ppl could play around with it in the meanwhile > > and report all problems to me, so I can fix them next weekend. > > Some initial thoughts while looking through the spec file: > > It would be nice to be able to keep the html docs out of /var/www/html. > It may be a bit debatable as to where the best location would be, > possibly /var/www/open-xchange, /usr/share/open-xchange/.... or > something. Then just add a open-xchange.conf to /etc/httpd/conf.d/ that > aliases the directory appropriately. Knowing how OX is, that may not be > possible without totally dorking stuff up. How about dropping a file into /etc/httpd/conf.d/ that will "Alias" the HTML documentation into the web space, but keep the documentation under /usr/share/doc/package-version/ (though, I would love to see version disappear from those directory names, for just this reason, among others). -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Wed Feb 22 16:50:33 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 22 Feb 2006 17:50:33 +0100 (CET) Subject: Open Xchange for FC5 with GCJ 4.1 In-Reply-To: <1140626527.3934.24.camel@dhollis-lnx.sunera.com> References: <1140392039.17385.390.camel@xpc.home.erwinrol.com> <1140626527.3934.24.camel@dhollis-lnx.sunera.com> Message-ID: <39173.192.54.193.25.1140627033.squirrel@rousalka.dyndns.org> Le Mer 22 f?vrier 2006 17:42, David Hollis a ?crit : > You really don't have to extract the WAR files during RPM build do you? > Can't you just plop the .war in the /var/lib/tomcat5/webapps dir and it > will take care of everything? Though I suppose you lose the RPM owning > those files... hmm, I don't know enough about tomcat app deployment to > know which way is best. Tomcat will unzip wars unconditionnally before using them, so you loose all the rpm and unix file features for no win (a net loss actually since you'll get two webapp versions on disk) -- Nicolas Mailhot From dragoran at feuerpokemon.de Wed Feb 22 16:55:42 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Wed, 22 Feb 2006 17:55:42 +0100 Subject: Hotplug: no more fstab entries In-Reply-To: <20060222153244.002ea18c@dhcp05.addix.net> References: <20060222153244.002ea18c@dhcp05.addix.net> Message-ID: <43FC978E.6040006@feuerpokemon.de> Ralf Ertzinger wrote: >Hi. > >For some time now plugging in a new device does not create an entry in >/etc/fstab any more. The device shows up in nautilus just fine and can be >mounted and unmounted. Working from the command line is quite a hassle, though >(just like in pre-udev-days). > >Is this intentional? > > > gnome-mount is used for mounts in the desktop now, so no fstab entrys are needed. why are you require them? you only have to know where the device is mounted and which device it is if you are working from the command line. From gauret at free.fr Wed Feb 22 16:59:37 2006 From: gauret at free.fr (Aurelien Bompard) Date: Wed, 22 Feb 2006 17:59:37 +0100 Subject: Multiple concurrent versions of Python References: <48385.192.54.193.25.1140605725.squirrel@rousalka.dyndns.org> <10428.192.54.193.25.1140612258.squirrel@rousalka.dyndns.org> <17264.192.54.193.25.1140626141.squirrel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot wrote: > Like I wrote, this is as bad as closed software tools ;( I guess that > means Zope deos not care about fedora. Well, no they don't. Still, I think we should care about Zope, because it is a useful piece of software, very wildly used. And it is considered for our CMS : http://fedoraproject.org/wiki/Websites/CMS The Java community does not care about Fedora either, yet we did a lot of work to have Java in Fedora (I know it is a bit stretched). Working on Zope to have a better support for it in Fedora seems the best solution. The question is : who is interested ? Who will do it ? Aur?lien. -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr Recursion: (n.) See "Recursion". From nicolas.mailhot at laposte.net Wed Feb 22 17:00:21 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 22 Feb 2006 18:00:21 +0100 (CET) Subject: Open Xchange for FC5 with GCJ 4.1 In-Reply-To: <200602220950.38360.lamont@gurulabs.com> References: <1140392039.17385.390.camel@xpc.home.erwinrol.com> <1140626527.3934.24.camel@dhollis-lnx.sunera.com> <200602220950.38360.lamont@gurulabs.com> Message-ID: <51733.192.54.193.25.1140627621.squirrel@rousalka.dyndns.org> Le Mer 22 f?vrier 2006 17:50, Lamont R. Peterson a ?crit : > How about dropping a file into /etc/httpd/conf.d/ that will "Alias" the > HTML > documentation into the web space, but keep the documentation > under /usr/share/doc/package-version/ The security people will hate this > (though, I would love to see version > disappear from those directory names, for just this reason, among others). How about defining a clear root for web-exportable doc ? (apache manuals, webapp manuals, etc) -- Nicolas Mailhot From notting at redhat.com Wed Feb 22 17:05:20 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 22 Feb 2006 12:05:20 -0500 Subject: The future of Linux - architecture and package inter-dependencies In-Reply-To: <200602220951.k1M9p4Yh015409@tiffany.internal.tigress.co.uk> References: <200602220951.k1M9p4Yh015409@tiffany.internal.tigress.co.uk> Message-ID: <20060222170520.GC5568@devserv.devel.redhat.com> Ron Yorston (rmy at tigress.co.uk) said: > Now, Fedora Core isn't a platform we support, but we do support RHEL. > So, thinking ahead, if OpenMotif is moved to Extras in FC6 or FC7 what > happens to it in RHEL6 (or whatever)? Someone from RH almost certainly would pick up a version from Extras and build it for whatever RHEL release they're developing at the time, if it's something needed for RHEL. Bill From mailinglists at erwinrol.com Wed Feb 22 17:07:54 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 22 Feb 2006 18:07:54 +0100 Subject: Open Xchange for FC5 with GCJ 4.1 In-Reply-To: <1140626527.3934.24.camel@dhollis-lnx.sunera.com> References: <1140392039.17385.390.camel@xpc.home.erwinrol.com> <1140626527.3934.24.camel@dhollis-lnx.sunera.com> Message-ID: <1140628075.30396.84.camel@xpc.home.erwinrol.com> Hey David, Please keep in mind the first priority is to figure out how it can be compiled, after that it can be cleaned up. On Wed, 2006-02-22 at 11:42 -0500, David Hollis wrote: > On Mon, 2006-02-20 at 00:33 +0100, Erwin Rol wrote: > It would be nice to be able to keep the html docs out of /var/www/html. > It may be a bit debatable as to where the best location would be, > possibly /var/www/open-xchange, /usr/share/open-xchange/.... or > something. Then just add a open-xchange.conf to /etc/httpd/conf.d/ that > aliases the directory appropriately. Knowing how OX is, that may not be > possible without totally dorking stuff up. Hmmm maybe the files in /usr/share/open-xchange/bla and a symlink from /var/www/html/ to that dir? > I really don't like having to have database names, passwords, LDAP dns > and such specified at build time, but I don't think OX gives any > alternatives.... sigh.... Yes that is a pain, and i plan to fix it. The database and LDAP-DN names are needed now because Open Xchange uses autoconf to generate scripts with the names in them, and thats just a bit stupid i think. For the passwords i guess there is not much choice but to leave them, problably as a easy grep-able something like CHANGEME. The install docu should take care of the rest. > Javamail - couldn't you have the OX spec depend on javamail >= 1.3.0 and > have the ox_javamail.spec have a "Provides: javamail 1.3.0" or whatnot? > That would allow newer javamail rpms to replace the ox_javamail when the > time comes and everything can continue playing nice. This was just one big hack, to not destroy a working javamail install. It falls under the "it was quick and worked for me" :-) The reall fix is ofcourse to provide patches to the javamail ppl and to wait for the next release of javamail (which will probably sooner than a real stable OX :-) > You really don't have to extract the WAR files during RPM build do you? > Can't you just plop the .war in the /var/lib/tomcat5/webapps dir and it > will take care of everything? Though I suppose you lose the RPM owning > those files... hmm, I don't know enough about tomcat app deployment to > know which way is best. Yeah the reason was that i wanted to have the RPM own those files, maybe some tomcat/rpm guru knows the correct way to do this. > The gcj.patch file seems to hard code some .jars that can be specfied > with configure. This could bite you later. It looks like that patch > tackles a bunch of different issues, so it would be best to split it > out. The gcj.patch is currently nothing more than a diff between a original and hacked tree. It has a lot of whitespace changes too that are not really needed but sneaked in. > A lot of things might be useful to send upstream, some may be > specific to getting the package to build with Fedora, etc. Check out > the kernel RPMS for examples of breaking out patches. As things get > merged upstream, become outdated, etc, it's very easy to remove them > from the spec. You probably don't want to have to maintain a parallel > source tree to generate patches. Yep that was the plan, but since this is a serious trail and error debugging the two tree thing was faster for now. And since OX is in RC stage no patches will be accepted anyway at the moment. Thank you for your reply, ideas and hints, which are certainly useful. - Erwin From notting at redhat.com Wed Feb 22 17:08:29 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 22 Feb 2006 12:08:29 -0500 Subject: Non-free Extras? In-Reply-To: <43FBA1CD.4020908@gmail.com> References: <43FBA1CD.4020908@gmail.com> Message-ID: <20060222170829.GD5568@devserv.devel.redhat.com> Eric Mesa (ericsbinaryworld at gmail.com) said: > are issues with their ffmpeg and mp3 codecs, but could these issues be > solved simply by designating their repositories as non-free? There's a difference between 'not free' and 'not legal'. So, no. Bill From fedora-devel-list at cygnusx-1.org Wed Feb 22 17:11:39 2006 From: fedora-devel-list at cygnusx-1.org (Nathan Grennan) Date: Wed, 22 Feb 2006 09:11:39 -0800 Subject: rlocate vs. mlocate In-Reply-To: <43FBBF3D.2030006@volny.cz> References: <43FB5C68.8070205@cygnusx-1.org> <43FBAF24.5000607@volny.cz> <43FBB98B.4060300@cygnusx-1.org> <43FBBF3D.2030006@volny.cz> Message-ID: <43FC9B4B.8030301@cygnusx-1.org> >> It sounds like someone still needs to write a inotify version of >> locate. I have no problem with a light weight daemon that would just >> reindex the locate database based on information feed to it by the >> kernel via inotify. >> > I'm not an inotify expert, nevertheless I think there are two "gritty > programming details" to solve. First, inotify doesn't work over network > filesystems, so it isn't possible to guarantee instantaneous update in > general, and a periodic scan is necessary anyway. Second, inodes of all > watched directories have to be kept in memory; on my laptop that would > be roughly 16000 inodes, which is about 10 MB of memory wasted for > locate; consider a file server with a few terabytes of storage. (To > prevent this pinning of kernel memory, inotify has a configurable limit > on the number of watches, which is 8192 by default.) > > I see 10mb as nothing, so much more than that gets wasted on others stuff. As for terabytes, people could disable it, or may also have gigabytes of memory. >> It would be an almost instantaneous replacement for >> both find and locate. >> > No, find(1) is specified by SUSv3, which explicitly states "The find > utility shall recursively descend the directory hierarchy...". Because > other programs can detect whether find(1) was traversing the subtree, we > can't optimize it out. > > I am not sure I quite agree with SUSv3 on this point, or even your interpretation of it, but even if it can't be changed, we could make another command with the same syntax that instead just hits the database. > In my experience the file is not moving in these cases, but that's of > course not a statistically relevant sample It isn't about the file moving, it is about not remembering where the file is located and wanting a quick search. Though things do move with time. Especially when you update packages and their is a new maintainer. From mailinglists at erwinrol.com Wed Feb 22 17:09:47 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 22 Feb 2006 18:09:47 +0100 Subject: Open Xchange for FC5 with GCJ 4.1 In-Reply-To: <39173.192.54.193.25.1140627033.squirrel@rousalka.dyndns.org> References: <1140392039.17385.390.camel@xpc.home.erwinrol.com> <1140626527.3934.24.camel@dhollis-lnx.sunera.com> <39173.192.54.193.25.1140627033.squirrel@rousalka.dyndns.org> Message-ID: <1140628187.30396.87.camel@xpc.home.erwinrol.com> On Wed, 2006-02-22 at 17:50 +0100, Nicolas Mailhot wrote: > Le Mer 22 f?vrier 2006 17:42, David Hollis a ?crit : > > > You really don't have to extract the WAR files during RPM build do you? > > Can't you just plop the .war in the /var/lib/tomcat5/webapps dir and it > > will take care of everything? Though I suppose you lose the RPM owning > > those files... hmm, I don't know enough about tomcat app deployment to > > know which way is best. > > Tomcat will unzip wars unconditionnally before using them, so you loose > all the rpm and unix file features for no win (a net loss actually since > you'll get two webapp versions on disk) and what will happen when you uninstall the RPM ? Or when you do a rpm -qf on one of the webapp/servlet files ? The idea was to make RPM aware that those files belong to the OX package. - Erwin From notting at redhat.com Wed Feb 22 17:12:27 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 22 Feb 2006 12:12:27 -0500 Subject: Results for install and remove tests for FC-Devel In-Reply-To: <43FC3ECA.9020100@redhat.com> References: <43FC3ECA.9020100@redhat.com> Message-ID: <20060222171227.GE5568@devserv.devel.redhat.com> Phil Knirsch (pknirsch at redhat.com) said: > As i've written last Friday, i have been running a complete install and > removal test for all packages of the Friday snapshot of FC-Devel. Is it possible to get this filtered into bugzilla without a herculean amount of manual effort? Bill From gauret at free.fr Wed Feb 22 17:16:57 2006 From: gauret at free.fr (Aurelien Bompard) Date: Wed, 22 Feb 2006 18:16:57 +0100 Subject: Multiple concurrent versions of Python References: <1140625979.16403.6.camel@orodruin.boston.redhat.com> Message-ID: Jeremy Katz wrote: > I really think that this needs to be resolved by making those apps work > better with more current versions of python. By that argument, what if > someone wanted to build an app which was only "supported" on a 2.4 > kernel -- would you argue that we should also add the infrastructure for > supporting a variety of incompatible kernel versions? Agreed, the right way is to make Zope work with python 2.4. But now, how to make that a reality ? Zope says : "Python 2.4.X will be supported when a security audit took place" I maintain the Zope rpm, but I sure can't do such a security audit. Does that mean Zope will remain unsupported in Fedora ? What alternative do we have ? > So now to upgrade Core from one version of python to another, I have to > touch every python app, even if they don't install files into > python_sitelib? No, if they don't install file into sitelib, they can run with whatever version was chosen by alternatives. Can't they ? > And not just a rebuild either, I have to make actual > changes to the included scripts. Where currently, if I just rebuild > with a "correct" python package, it will DTRT. The version change can probably be done inside the spec file. Most of the support for multiple pythons could be handled by the buildsystem automatically. I'm just proposing what I though we could do on the packager's side. But if we can improve upstream instead, it would be Better, and more in line with the Fedora Way. But will we do it ? Saying "we should improve upstream instead" and doing nothing is not going to help anyone. I wish I could help the upstream audit Zope on python 2.4, but that is way above my knowledge at the moment. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Millions long for immortality who do not know what to do with themselves on a rainy Sunday afternoon." -- Susan Ertz From dmalcolm at redhat.com Wed Feb 22 17:25:50 2006 From: dmalcolm at redhat.com (David Malcolm) Date: Wed, 22 Feb 2006 12:25:50 -0500 Subject: Evolution Printing (Was Re: rawhide report: 20060222 changes) In-Reply-To: <200602221522.k1MFMlVf027874@porkchop.devel.redhat.com> References: <200602221522.k1MFMlVf027874@porkchop.devel.redhat.com> Message-ID: <1140629151.18057.3.camel@cassandra.boston.redhat.com> On Wed, 2006-02-22 at 10:22 -0500, Build System wrote: > > > Updated Packages: > > NetworkManager-0.5.1-13.cvs20060221 > ----------------------------------- > * Tue Feb 21 2006 Dan Williams 0.5.1-13.cvs20060221 > - Add BuildRequires: libnl-devel (#rh179438#) > - Fix libnm_glib to not clobber an application's existing dbus connection > (#rh177546#, gnome.org #326572) Looks like this does indeed fix printing within Evolution Thanks Dan > - libnotify support > - AP compatibility fixes > [snip] Dave From pbrobinson at gmail.com Wed Feb 22 17:32:26 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 22 Feb 2006 17:32:26 +0000 Subject: Evolution Printing (Was Re: rawhide report: 20060222 changes) In-Reply-To: <1140629151.18057.3.camel@cassandra.boston.redhat.com> References: <200602221522.k1MFMlVf027874@porkchop.devel.redhat.com> <1140629151.18057.3.camel@cassandra.boston.redhat.com> Message-ID: <5256d0b0602220932i43291a3n618e947d1b0271f9@mail.gmail.com> On 2/22/06, David Malcolm wrote: > On Wed, 2006-02-22 at 10:22 -0500, Build System wrote: > > > > > > Updated Packages: > > > > NetworkManager-0.5.1-13.cvs20060221 > > ----------------------------------- > > * Tue Feb 21 2006 Dan Williams 0.5.1-13.cvs20060221 > > - Add BuildRequires: libnl-devel (#rh179438#) > > - Fix libnm_glib to not clobber an application's existing dbus connection > > (#rh177546#, gnome.org #326572) > > Looks like this does indeed fix printing within Evolution Looking at the bug it seems similar to the one I was experiencing... time to test when I get home. It had references in the debug output similar to the stuff in that bug. FYI bug 179546 Cheers, Pete From laroche at redhat.com Wed Feb 22 17:38:01 2006 From: laroche at redhat.com (Florian La Roche) Date: Wed, 22 Feb 2006 18:38:01 +0100 Subject: Multiple concurrent versions of Python In-Reply-To: <1140625979.16403.6.camel@orodruin.boston.redhat.com> References: <1140625979.16403.6.camel@orodruin.boston.redhat.com> Message-ID: <20060222173801.GA9027@dudweiler.stuttgart.redhat.com> > I really think that this needs to be resolved by making those apps work > better with more current versions of python. By that argument, what if > someone wanted to build an app which was only "supported" on a 2.4 > kernel -- would you argue that we should also add the infrastructure for > supporting a variety of incompatible kernel versions? zope/plone from FE do work fine for me on FC4. At least with my very, very limited testing I did. I think their point is that they promote the python versions they use themselves, but there are also no known breakages for newer python versions. regards, Florian La Roche From gnomeuser at gmail.com Wed Feb 22 17:51:29 2006 From: gnomeuser at gmail.com (David Nielsen) Date: Wed, 22 Feb 2006 18:51:29 +0100 Subject: Proposing a switch to Tango In-Reply-To: <1140628870.2464.42.camel@halflap> References: <1140557623.24450.12.camel@price.stavtrup-st.dk> <1140628870.2464.42.camel@halflap> Message-ID: <1140630689.2107.10.camel@price.stavtrup-st.dk> ons, 22 02 2006 kl. 12:21 -0500, skrev Ray Strode: > Hi, > > > I would like to propose replacing the bluecurve icon theme with > > tango[1]. > So it's definitely too late for FC5, given that test3 is already out. > > My thoughts are we should wait until GNOME adopts it. If upstream GNOME > adopts it, it would be a lot easier choice to make. > > Just my thoughts, though... I specifically suggested this be done for the FC6 cycle. Upstream is not looking to adopt Tango out of the fear that without vendor support, it will look like a GNOME only project and thus scare off the KDE crowd. Or so it seems. Thus vendor buy in is very important, I for one, would love to welcome my new Tango overlords to Fedora since I find their style very pleasing and I agree with the aims out getting a unified icon standard. It sounds like The tango developers and artists are very keen on cooperating with us to make this happen. - David -- Obligatory shameless blog plug - the GNOME commentary located at: www.lovesunix.net/blog From nicolas.mailhot at laposte.net Wed Feb 22 17:58:40 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 22 Feb 2006 18:58:40 +0100 Subject: Open Xchange for FC5 with GCJ 4.1 In-Reply-To: <1140628187.30396.87.camel@xpc.home.erwinrol.com> References: <1140392039.17385.390.camel@xpc.home.erwinrol.com> <1140626527.3934.24.camel@dhollis-lnx.sunera.com> <39173.192.54.193.25.1140627033.squirrel@rousalka.dyndns.org> <1140628187.30396.87.camel@xpc.home.erwinrol.com> Message-ID: <1140631120.22535.8.camel@rousalka.dyndns.org> Le mercredi 22 f?vrier 2006 ? 18:09 +0100, Erwin Rol a ?crit : > On Wed, 2006-02-22 at 17:50 +0100, Nicolas Mailhot wrote: > > Le Mer 22 f?vrier 2006 17:42, David Hollis a ?crit : > > > > > You really don't have to extract the WAR files during RPM build do you? > > > Can't you just plop the .war in the /var/lib/tomcat5/webapps dir and it > > > will take care of everything? Though I suppose you lose the RPM owning > > > those files... hmm, I don't know enough about tomcat app deployment to > > > know which way is best. > > > > Tomcat will unzip wars unconditionnally before using them, so you loose > > all the rpm and unix file features for no win (a net loss actually since > > you'll get two webapp versions on disk) > > and what will happen when you uninstall the RPM ? Or when you do a rpm > -qf on one of the webapp/servlet files ? The idea was to make RPM aware > that those files belong to the OX package. That's why you should never package wars in rpms, only the unzipped version. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Wed Feb 22 18:05:20 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 22 Feb 2006 19:05:20 +0100 Subject: Multiple concurrent versions of Python In-Reply-To: References: <48385.192.54.193.25.1140605725.squirrel@rousalka.dyndns.org> <10428.192.54.193.25.1140612258.squirrel@rousalka.dyndns.org> <17264.192.54.193.25.1140626141.squirrel@rousalka.dyndns.org> Message-ID: <1140631520.22535.15.camel@rousalka.dyndns.org> Le mercredi 22 f?vrier 2006 ? 17:59 +0100, Aurelien Bompard a ?crit : > Nicolas Mailhot wrote: > > Like I wrote, this is as bad as closed software tools ;( I guess that > > means Zope deos not care about fedora. > > Well, no they don't. Still, I think we should care about Zope, because it is > a useful piece of software, very wildly used. And it is considered for our > CMS : http://fedoraproject.org/wiki/Websites/CMS > The Java community does not care about Fedora either, yet we did a lot of > work to have Java in Fedora (I know it is a bit stretched). And, actually, the FOSS part of the Java community did help as they could. > Working on Zope to have a better support for it in Fedora seems the best > solution. The question is : who is interested ? Who will do it ? Looking at the Zope site they also complain about Suse so I guess it's them against two major distributions... Between Red Hat, Fedora and Suse python hackers surely someone can convince them they're not reasonable? FC5 zope is probably cooked though. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From mclasen at redhat.com Wed Feb 22 18:13:30 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 22 Feb 2006 13:13:30 -0500 Subject: Proposing a switch to Tango In-Reply-To: <1140630689.2107.10.camel@price.stavtrup-st.dk> References: <1140557623.24450.12.camel@price.stavtrup-st.dk> <1140628870.2464.42.camel@halflap> <1140630689.2107.10.camel@price.stavtrup-st.dk> Message-ID: <1140632010.23024.32.camel@golem.boston.redhat.com> On Wed, 2006-02-22 at 18:51 +0100, David Nielsen wrote: > ons, 22 02 2006 kl. 12:21 -0500, skrev Ray Strode: > > Hi, > > > > > I would like to propose replacing the bluecurve icon theme with > > > tango[1]. > > So it's definitely too late for FC5, given that test3 is already out. > > > > My thoughts are we should wait until GNOME adopts it. If upstream GNOME > > adopts it, it would be a lot easier choice to make. > > > > Just my thoughts, though... > > I specifically suggested this be done for the FC6 cycle. > > Upstream is not looking to adopt Tango out of the fear that without > vendor support, it will look like a GNOME only project and thus scare > off the KDE crowd. Or so it seems. Thus vendor buy in is very important, > I for one, would love to welcome my new Tango overlords to Fedora since > I find their style very pleasing and I agree with the aims out getting a > unified icon standard. > > It sounds like The tango developers and artists are very keen on > cooperating with us to make this happen. > The first step in making this happen is to switch the existing Gnome icon theme to the (still unfinished) icon naming spec, and make sure Gnome actually works with it. Once that is done, switching to Tango should be relatively painless. Note that the switchover of the gnome icon theme to the naming spec was undertaken in a very poorly managed fashion during 2.13, so it had to be reverted. Matthias From toshio at tiki-lounge.com Wed Feb 22 18:19:15 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 22 Feb 2006 10:19:15 -0800 Subject: Multiple concurrent versions of Python In-Reply-To: References: <1140625979.16403.6.camel@orodruin.boston.redhat.com> Message-ID: <1140632355.3286.36.camel@localhost> On Wed, 2006-02-22 at 18:16 +0100, Aurelien Bompard wrote: > Jeremy Katz wrote: > > I really think that this needs to be resolved by making those apps work > > better with more current versions of python. By that argument, what if > > someone wanted to build an app which was only "supported" on a 2.4 > > kernel -- would you argue that we should also add the infrastructure for > > supporting a variety of incompatible kernel versions? > > Agreed, the right way is to make Zope work with python 2.4. > But now, how to make that a reality ? Zope says : > "Python 2.4.X will be supported when a security audit took place" > I maintain the Zope rpm, but I sure can't do such a security audit. > Does that mean Zope will remain unsupported in Fedora ? What alternative do > we have ? > What about helping to port Plone to Zope 2.9.x? Is the Plone project working on this/open to this kind of contribution? Does Plone currently run on zope-2.9/python-2.4 but just is not "supported"? Some background for those that want it: Zope maintains several branches. Currently they are pushing 2.9.x and 3.2.x (which is incompatible with Zope 2). python-2.4 is the supported platform for both of these. Plone is a major add-on for Zope 2 which makes CMS work much easier. Plone lists Zope-2.8 (which the Zope devs say is most definitely not supported on python-2.4) as its supported platform. Zope 3 has features which are supposed to largely replace the need for Plone but that doesn't help people who have already deployed a Zope+Plone solution. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From mailinglists at erwinrol.com Wed Feb 22 18:27:53 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 22 Feb 2006 19:27:53 +0100 Subject: Open Xchange for FC5 with GCJ 4.1 In-Reply-To: <1140631120.22535.8.camel@rousalka.dyndns.org> References: <1140392039.17385.390.camel@xpc.home.erwinrol.com> <1140626527.3934.24.camel@dhollis-lnx.sunera.com> <39173.192.54.193.25.1140627033.squirrel@rousalka.dyndns.org> <1140628187.30396.87.camel@xpc.home.erwinrol.com> <1140631120.22535.8.camel@rousalka.dyndns.org> Message-ID: <1140632873.30396.96.camel@xpc.home.erwinrol.com> On Wed, 2006-02-22 at 18:58 +0100, Nicolas Mailhot wrote: > Le mercredi 22 f?vrier 2006 ? 18:09 +0100, Erwin Rol a ?crit : > > and what will happen when you uninstall the RPM ? Or when you do a rpm > > -qf on one of the webapp/servlet files ? The idea was to make RPM aware > > that those files belong to the OX package. > > That's why you should never package wars in rpms, only the unzipped > version. To be honest i didn't think about that, probably because i don't know tomcat to well and thought that the war file must be installed. So the solution is to simply remove the .wars from the RPM ? Is the unzipping of the wars during the build acceptable or should there be found another solution ? - Erwin From mandreiana.lists at gmail.com Wed Feb 22 18:36:29 2006 From: mandreiana.lists at gmail.com (Marius Andreiana) Date: Wed, 22 Feb 2006 20:36:29 +0200 Subject: closing older bug reports without looking = bad practice ? In-Reply-To: <43FC10F5.6090206@mharris.ca> References: <1140463650.3252.30.camel@mariusa-ro.ro.oracle.com> <43FC10F5.6090206@mharris.ca> Message-ID: <1140633389.3250.3.camel@mariusa-ro.ro.oracle.com> On Wed, 2006-02-22 at 02:21 -0500, Mike A. Harris wrote: > Preface: My response is rather verbose, because I believe this is a > very important issue, and is one I've put a tremendous amount of thought > and effort into for the last 2-4 years, so I have a lot of ideas and > opinions to express. Thanks Mike for the verbose and useful response! It really shows what does it mean to be an Operating System developer and the fact that there isn't an easy solution to decrease the number of bugs (both in code and reported). Hoping that fedora-test members will be able to help a little, -- Marius Andreiana From nicolas.mailhot at laposte.net Wed Feb 22 18:47:52 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 22 Feb 2006 19:47:52 +0100 Subject: Open Xchange for FC5 with GCJ 4.1 In-Reply-To: <1140632873.30396.96.camel@xpc.home.erwinrol.com> References: <1140392039.17385.390.camel@xpc.home.erwinrol.com> <1140626527.3934.24.camel@dhollis-lnx.sunera.com> <39173.192.54.193.25.1140627033.squirrel@rousalka.dyndns.org> <1140628187.30396.87.camel@xpc.home.erwinrol.com> <1140631120.22535.8.camel@rousalka.dyndns.org> <1140632873.30396.96.camel@xpc.home.erwinrol.com> Message-ID: <1140634072.22535.18.camel@rousalka.dyndns.org> Le mercredi 22 f?vrier 2006 ? 19:27 +0100, Erwin Rol a ?crit : > On Wed, 2006-02-22 at 18:58 +0100, Nicolas Mailhot wrote: > > Le mercredi 22 f?vrier 2006 ? 18:09 +0100, Erwin Rol a ?crit : > > > > and what will happen when you uninstall the RPM ? Or when you do a rpm > > > -qf on one of the webapp/servlet files ? The idea was to make RPM aware > > > that those files belong to the OX package. > > > > That's why you should never package wars in rpms, only the unzipped > > version. > > To be honest i didn't think about that, probably because i don't know > tomcat to well and thought that the war file must be installed. > > So the solution is to simply remove the .wars from the RPM ? Is the > unzipping of the wars during the build acceptable or should there be The solution is just to package the unzipped version, not the wars themselves. Tomcat sees the unzipped version and uses it directly. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From bdpepple at ameritech.net Wed Feb 22 18:15:31 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Wed, 22 Feb 2006 13:15:31 -0500 Subject: Proposing a switch to Tango In-Reply-To: <1140630689.2107.10.camel@price.stavtrup-st.dk> References: <1140557623.24450.12.camel@price.stavtrup-st.dk> <1140628870.2464.42.camel@halflap> <1140630689.2107.10.camel@price.stavtrup-st.dk> Message-ID: <1140632132.2693.7.camel@shuttle.273piedmont.org> On Wed, 2006-02-22 at 18:51 +0100, David Nielsen wrote: > I specifically suggested this be done for the FC6 cycle. > > Upstream is not looking to adopt Tango out of the fear that without > vendor support, it will look like a GNOME only project and thus scare > off the KDE crowd. Or so it seems. Thus vendor buy in is very important, > I for one, would love to welcome my new Tango overlords to Fedora since > I find their style very pleasing and I agree with the aims out getting a > unified icon standard. > > It sounds like The tango developers and artists are very keen on > cooperating with us to make this happen. I agree with Ray that we should wait for GNOME to adopt it. Tango is relatively new, and most GNOME apps don't have icons that have been tangoized. Due to the different color palettes (which I have to admit that I hate) used, they stick out horribly and don't provide a very unified look. If there is a demand for Tango, maybe it should be submitted to FE. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From dedourek at unb.ca Wed Feb 22 18:53:01 2006 From: dedourek at unb.ca (John DeDourek) Date: Wed, 22 Feb 2006 14:53:01 -0400 Subject: Hotplug: no more fstab entries In-Reply-To: <43FC978E.6040006@feuerpokemon.de> References: <20060222153244.002ea18c@dhcp05.addix.net> <43FC978E.6040006@feuerpokemon.de> Message-ID: <43FCB30D.2020509@unb.ca> dragoran wrote: > Ralf Ertzinger wrote: > >> Hi. >> >> For some time now plugging in a new device does not create an entry in >> /etc/fstab any more. The device shows up in nautilus just fine and >> can be >> mounted and unmounted. Working from the command line is quite a >> hassle, though >> (just like in pre-udev-days). >> >> Is this intentional? >> >> >> > gnome-mount is used for mounts in the desktop now, so no fstab entrys > are needed. > why are you require them? > you only have to know where the device is mounted and which device it > is if you are working from the command line. > Which some of us do quite a bit of for specialized work. I can't use a Linux distro that doesn't have reasonable functionality when worked from the command line, e.g. from a terminal window, from a console, or via an ssh connection. From nicolas.mailhot at laposte.net Wed Feb 22 19:02:06 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 22 Feb 2006 20:02:06 +0100 Subject: The future of Linux - architecture and package In-Reply-To: <20060222114205.GA20029@devserv.devel.redhat.com> References: <20060221141944.GA25869@devserv.devel.redhat.com> <20060221165534.GA10234@devserv.devel.redhat.com> <1140545472.12119.1.camel@rousalka.dyndns.org> <20060221182037.GA17897@devserv.devel.redhat.com> <1140558444.13224.2.camel@rousalka.dyndns.org> <20060222114205.GA20029@devserv.devel.redhat.com> Message-ID: <1140634927.22535.21.camel@rousalka.dyndns.org> Le mercredi 22 f?vrier 2006 ? 06:42 -0500, Alan Cox a ?crit : > On Tue, Feb 21, 2006 at 10:47:24PM +0100, Nicolas Mailhot wrote: > > Waiting Shelter R001 seems to render and print fine with rawhide evince > > (apart from the usual "all the world is a Letter printer - let's f*-up > > A4 borders" Gnome print bug) > > Is the graffiti on a black background or on texture that is where the > previous one I tried broke - it should be on texture Damn, you're right :( -> http://bugzilla.gnome.org/show_bug.cgi?id=332222 -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ellson at research.att.com Wed Feb 22 19:07:36 2006 From: ellson at research.att.com (John Ellson) Date: Wed, 22 Feb 2006 14:07:36 -0500 Subject: relocatable rpm .spec question Message-ID: <43FCB678.8030102@research.att.com> I'm trying to make an rpm relocatable. I've added "Prefix: /usr" to my .spec file and by using "rpm -ivh --prefix=/home/ellson/usr foobar.*.rpm" the package installs binaries correctly in new location. But I have a %post containing "%{_bindir}/foo" that isn't getting relocated properly. Its still looking for /usr/bin/foo instead of /home/ellson/usr/bin/foo. I tried "%{prefix}/bin/foo" but it still resolves to /usr/bin/foo Is there a variable set by the --prefix option that I can use in %post ? I couldn't find a solution in: http://fedora.redhat.com/docs/drafts/rpm-guide-en/ch10s05.html John From jspaleta at gmail.com Wed Feb 22 19:10:42 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 22 Feb 2006 14:10:42 -0500 Subject: Hotplug: no more fstab entries In-Reply-To: <43FCB30D.2020509@unb.ca> References: <20060222153244.002ea18c@dhcp05.addix.net> <43FC978E.6040006@feuerpokemon.de> <43FCB30D.2020509@unb.ca> Message-ID: <604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com> On 2/22/06, John DeDourek wrote: > Which some of us do quite a bit of for specialized work. I can't use > a Linux distro that doesn't have reasonable functionality when worked > from the command line, e.g. from a terminal window, from a console, > or via an ssh connection. Writing your own mount commands from a terminal or from the text console is unreasonable in your estimation? Using the new gnome-mount command on the cmdline in these situations to mimic what the gnome desktop's automounter does is unreasonable? gnome-mount --help the associated gnome-mount tools are still maturing. I'm quite sure there is still room for feedback to make their operation more palatable. But I find it hard to call there existance and their current level of functionality unreasonable replacements for what we had before. If anything gnome-mount-* is a way forward compared to directly editting the hal policy files.. especially if gnome-mount-properties shapes up nicely to provide but a gui and cmdline way of creating per-user and per-device mount policy. -jef From nmiell at comcast.net Wed Feb 22 19:40:20 2006 From: nmiell at comcast.net (Nicholas Miell) Date: Wed, 22 Feb 2006 11:40:20 -0800 Subject: libstdc++-so7 info? In-Reply-To: <20060222120933.GZ24295@devserv.devel.redhat.com> References: <20060222120933.GZ24295@devserv.devel.redhat.com> Message-ID: <1140637220.2983.4.camel@entropy> On Wed, 2006-02-22 at 07:09 -0500, Jakub Jelinek wrote: > On Wed, Feb 22, 2006 at 07:06:45AM -0500, Neal Becker wrote: > > I noticed the libstdc++-so7 preview, but I haven't been able to find any > > information that summarizes what is new, compared with the current > > libstdc++. Any pointers? > > It is only included for scim purposes, please don't use it for anything > else. It contains various ABI breaking experimental STL changes that > are not applicable to libstdc++.so.6. > Oh great, they're breaking the ABI again!? When will those idiots learn... How about Fedora stops including all new versions of libstdc++ until the maintainers manage to wrap their tiny little minds around the concept of a "stable ABI"? Or else add -Bdirect and/or -Bgroup support to glibc's rtld. -- Nicholas Miell From pjones at redhat.com Wed Feb 22 19:42:36 2006 From: pjones at redhat.com (Peter Jones) Date: Wed, 22 Feb 2006 14:42:36 -0500 Subject: FC5 test3 -- dmraid broken? In-Reply-To: <1140626948.4113.18.camel@mentorng.gurulabs.com> References: <1140499892.3430.13.camel@mentorng.gurulabs.com> <1140536181.20618.2.camel@localhost.localdomain> <1140587745.3551.20.camel@mentorng.gurulabs.com> <1140617913.22131.5.camel@localhost.localdomain> <1140626948.4113.18.camel@mentorng.gurulabs.com> Message-ID: <1140637356.22131.8.camel@localhost.localdomain> On Wed, 2006-02-22 at 09:49 -0700, Dax Kelson wrote: > On Wed, 2006-02-22 at 09:18 -0500, Peter Jones wrote: > > > It's almost as if lvm isn't checking the dm volumes, but that shouldn't > > be the case with even remotely recent lvm2. > > For kicks I tried an initrd with the "rmparts" commands commented out. > > When I booted that I did get the expected "duplicate PV found selecting > foo" messages. I rebooted before any writes could happen (I think). Hrm. OK, that means it got farther. So try booting into the rescue environment and adding those drives into the lvm filters, and I'll try to figure out how to reproduce the failure. -- Peter From ericsbinaryworld at gmail.com Wed Feb 22 19:56:02 2006 From: ericsbinaryworld at gmail.com (Eric Mesa) Date: Wed, 22 Feb 2006 14:56:02 -0500 Subject: Non-free Extras? In-Reply-To: <43FC5A1B.4070106@cornell.edu> References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> <43FC1F67.7080607@argo.co.il> <20060222120630.GD20029@devserv.devel.redhat.com> <43FC5A1B.4070106@cornell.edu> Message-ID: <43FCC1D2.4020206@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ivan Gyurdiev wrote: > >>> They're giving away their drivers for free anyways. >>> >> >> >> Only in price, and then you pay a terrible price if you want to >> debug anything or your system isn't stable >> >> > > Right... but since I don't want the debug anything, and my system > is stable, I don't pay a terrible price. [if (false) => x] is true. > The system could destabilize in the future, at which point I'll > re-evaluate my use of Nvidia cards. Speaking of which, the nv > driver is rather unstable, and does not work for me at the moment - > just filed a bug... > > For the moment I haven't heard of an OSS solution with good > performance for 3D games.... or wireless drivers for atheros. Since > 3D games and wireless drivers are rather important to me, I accept > reality and use what's available. Surely my hardware working with > proprietary drivers is better than my hardware not working at all. > > I see no problem with using the livna repository, so I'm not sure > what this thread's all about. What would be useful is: - > development branch of the livna repository (it's constantly > out-of-sync for rawhide testers!) - some sort of ABI, so that > modules don't have to be recompiled for each and every kernel > (wasn't something like this under development in the 2.6 cycle? > arguments against it never made any sense to me) > The reason for my starting the thread was the fact that there are a myriad of repos out there for those of us who need (or "need" - depending on your point of view) access to non-free software. They overlap in a lot of places, but some have one app that others don't. However, mixing repos who don't work together can have bad results. So I was hoping we could unite them in, say, the Fedora-non-free and Fedora-tricky-licensing repos so that they could work together and maintain package consistency, etc. - -- Eric Mesa ericsbinaryworld at gmail.com http://www.ericsbinaryworld.com Note: All emails from this address should have a GPG signature. If you have the proper setup you can use this to confirm my identity and that the email was not changed in transit. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFD/MHSPvU+8ApmWXIRAvdaAJ9/cdJjAfrLxw+IEFD2rTob78M/YACgy5Ff acd6bKaHUGyHA5HJBTSmiks= =1uRT -----END PGP SIGNATURE----- From david at fubar.dk Wed Feb 22 20:16:00 2006 From: david at fubar.dk (David Zeuthen) Date: Wed, 22 Feb 2006 15:16:00 -0500 Subject: Hotplug: no more fstab entries In-Reply-To: <20060222153244.002ea18c@dhcp05.addix.net> References: <20060222153244.002ea18c@dhcp05.addix.net> Message-ID: <1140639360.2460.52.camel@daxter.boston.redhat.com> On Wed, 2006-02-22 at 15:32 +0100, Ralf Ertzinger wrote: > Hi. > > For some time now plugging in a new device does not create an entry in > /etc/fstab any more. The device shows up in nautilus just fine and can be > mounted and unmounted. Working from the command line is quite a hassle, though > (just like in pre-udev-days). > > Is this intentional? > It is intentional, yes. David From jakub at redhat.com Wed Feb 22 20:18:45 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 22 Feb 2006 15:18:45 -0500 Subject: libstdc++-so7 info? In-Reply-To: <1140637220.2983.4.camel@entropy> References: <20060222120933.GZ24295@devserv.devel.redhat.com> <1140637220.2983.4.camel@entropy> Message-ID: <20060222201844.GF24295@devserv.devel.redhat.com> On Wed, Feb 22, 2006 at 11:40:20AM -0800, Nicholas Miell wrote: > On Wed, 2006-02-22 at 07:09 -0500, Jakub Jelinek wrote: > > On Wed, Feb 22, 2006 at 07:06:45AM -0500, Neal Becker wrote: > > > I noticed the libstdc++-so7 preview, but I haven't been able to find any > > > information that summarizes what is new, compared with the current > > > libstdc++. Any pointers? > > > > It is only included for scim purposes, please don't use it for anything > > else. It contains various ABI breaking experimental STL changes that > > are not applicable to libstdc++.so.6. > > > > Oh great, they're breaking the ABI again!? When will those idiots > learn... > > How about Fedora stops including all new versions of libstdc++ until the > maintainers manage to wrap their tiny little minds around the concept of > a "stable ABI"? Please don't insult people who know about C++ ABI stuff far more than you apparently do. There are several C++ ABI bugs both on the compiler side (things you currently get with -fabi-version=0, PR22488 etc.) and several things in the STL land are simply not doable without ABI break, backwards compatibility in C++ world is a few orders of magnitude harder in C++ than in C. G++ 3.4/4.0/4.1 have C++ ABI compatibility and nobody said yet to my knowledge if 4.2 will or won't be compatible, libstdc++so7 is simply a playground for things that aren't doable without ABI break (similarly to -fabi-version=0). If/when it is decided to do an ABI break, all the stuff in there can be used. >From my own experience when I was doing the long double switch also in libstdc++, aiming for libstdc++.so.6 compatibility with both DFmode and TFmode long double, maintaining C++ ABI compatibility is a nightmare, you basically can't use symbol versioning and due to inheritance, inlining and ODR things are really hard to do. We included this in Fedora, because SCIM IM modules are written in C++ and as they need to be loaded into arbitrary Gtk (and KDE) applications, there is a big problem if the application uses some older libstdc++.so. This can be solved only with dlmopen (but then, SCIM IM modules use like 40 or 50 shared library dependencies, so dlmopen isn't really a good idea), or by namespace versioning, which is one of the things libstdc++so7 has. Jakub From hhoffman at ip-solutions.net Wed Feb 22 20:30:21 2006 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Wed, 22 Feb 2006 15:30:21 -0500 Subject: lastest selinux break Xen? Message-ID: <43FCC9DD.6090802@ip-solutions.net> Hi, Just updated and Xen seems to have been broken by the latest selinux patches? setenforce 0 allows Xen to operate. Thanks, Harry >From dmesg: audit(1019131266.041:374): avc: denied { write } for pid=2613 comm="ip" name="xend-debug.log" dev=dm-5 ino=491541 scontext=root:system_r:ifconfig_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file audit(1019131266.053:375): avc: denied { write } for pid=2613 comm="ip" name="privcmd" dev=proc ino=-268434128 scontext=root:system_r:ifconfig_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file audit(1019131266.053:376): avc: denied { write } for pid=2613 comm="ip" name="privcmd" dev=proc ino=-268434128 scontext=root:system_r:ifconfig_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file audit(1019131266.053:377): avc: denied { write } for pid=2613 comm="ip" name="privcmd" dev=proc ino=-268434128 scontext=root:system_r:ifconfig_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file audit(1019131266.065:378): avc: denied { append } for pid=2613 comm="ip" name="xend.log" dev=dm-5 ino=491540 scontext=root:system_r:ifconfig_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file audit(1019131266.065:379): avc: denied { write } for pid=2613 comm="ip" name="privcmd" dev=proc ino=-268434128 scontext=root:system_r:ifconfig_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file audit(1019131266.065:380): avc: denied { write } for pid=2613 comm="ip" name="privcmd" dev=proc ino=-268434128 scontext=root:system_r:ifconfig_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file audit(1019131266.073:381): avc: denied { write } for pid=2613 comm="ip" name="privcmd" dev=proc ino=-268434128 scontext=root:system_r:ifconfig_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file audit(1019131266.073:382): avc: denied { write } for pid=2613 comm="ip" name="privcmd" dev=proc ino=-268434128 scontext=root:system_r:ifconfig_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file audit(1019131266.073:383): avc: denied { read write } for pid=2613 comm="ip" name="[7503]" dev=sockfs ino=7503 scontext=root:system_r:ifconfig_t:s0 tcontext=root:system_r:initrc_t:s0 tclass=unix_stream_socket audit(1019131266.161:384): avc: denied { write } for pid=2615 comm="ip" name="privcmd" dev=proc ino=-268434128 scontext=root:system_r:ifconfig_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file audit(1019131266.169:385): avc: denied { write } for pid=2615 comm="ip" name="privcmd" dev=proc ino=-268434128 scontext=root:system_r:ifconfig_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file audit(1019131266.169:386): avc: denied { write } for pid=2615 comm="ip" name="privcmd" dev=proc ino=-268434128 scontext=root:system_r:ifconfig_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file audit(1019131266.169:387): avc: denied { append } for pid=2615 comm="ip" name="xend.log" dev=dm-5 ino=491540 scontext=root:system_r:ifconfig_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file audit(1019131266.169:388): avc: denied { write } for pid=2615 comm="ip" name="privcmd" dev=proc ino=-268434128 scontext=root:system_r:ifconfig_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file audit(1019131266.181:389): avc: denied { write } for pid=2615 comm="ip" name="privcmd" dev=proc ino=-268434128 scontext=root:system_r:ifconfig_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file audit(1019131266.181:390): avc: denied { write } for pid=2615 comm="ip" name="privcmd" dev=proc ino=-268434128 scontext=root:system_r:ifconfig_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file audit(1019131266.181:391): avc: denied { write } for pid=2615 comm="ip" name="privcmd" dev=proc ino=-268434128 scontext=root:system_r:ifconfig_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file audit(1019131266.189:392): avc: denied { read write } for pid=2615 comm="ip" name="[7503]" dev=sockfs ino=7503 scontext=root:system_r:ifconfig_t:s0 tcontext=root:system_r:initrc_t:s0 tclass=unix_stream_socket audit(1019131266.197:393): avc: denied { write } for pid=2616 comm="ip" name="privcmd" dev=proc ino=-268434128 scontext=root:system_r:ifconfig_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file audit(1019131266.209:394): avc: denied { write } for pid=2616 comm="ip" name="privcmd" dev=proc ino=-268434128 scontext=root:system_r:ifconfig_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file audit(1019131266.209:395): avc: denied { write } for pid=2616 comm="ip" name="privcmd" dev=proc ino=-268434128 scontext=root:system_r:ifconfig_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file audit(1019131266.209:396): avc: denied { append } for pid=2616 comm="ip" name="xend.log" dev=dm-5 ino=491540 scontext=root:system_r:ifconfig_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file >From /var/log/messages: Apr 18 08:01:52 n1-22-30 kernel: audit(1019131312.164:403): avc: denied { append } for pid=2709 comm="ifconfig" name="xen-hotplug.log" dev=dm-5 ino=491545 scontext=system_u:system_r:ifconfig_t:s0-s0:c0.c255 tcontext=system_u:object_r:var_log_t:s0 tclass=file -- Harry Hoffman Integrated Portable Solutions, LLC 877.846.5927 ext 1000 http://www.ip-solutions.net/ From jspaleta at gmail.com Wed Feb 22 20:37:25 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 22 Feb 2006 15:37:25 -0500 Subject: Non-free Extras? In-Reply-To: <43FCC1D2.4020206@gmail.com> References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> <43FC1F67.7080607@argo.co.il> <20060222120630.GD20029@devserv.devel.redhat.com> <43FC5A1B.4070106@cornell.edu> <43FCC1D2.4020206@gmail.com> Message-ID: <604aa7910602221237q1b6e5d9ag1736fb8798506c2b@mail.gmail.com> On 2/22/06, Eric Mesa wrote: > The reason for my starting the thread was the fact that there are a > myriad of repos out there for those of us who need (or "need" - > depending on your point of view) access to non-free software. They > overlap in a lot of places, but some have one app that others don't. > However, mixing repos who don't work together can have bad results. > So I was hoping we could unite them in, say, the Fedora-non-free and > Fedora-tricky-licensing repos so that they could work together and > maintain package consistency, etc. Livna has a community based process for package submission and becoming a package contributor does it not? What is stopping people from working inside the Livna community structure to legally provide the largest possible range of software that you seek which can not be part of the Fedora project? You can't force people to work together. Either they are willing to do so or they are not. I don't see how Fedora as a project can officially bless any single community effort over another. Even if they could, I don't think its necessarily appropriate for the project to do so. But each one of us can use their own personal influence to encourage others to contribute in a way that we see fit. I personally encourage people to contribute to livna when they can not contribute the package to Extras. And I would personally encourage you to do the same, if your goal is to get as much non-overlapping functionality centralized in as few repositories as possible...legally. -jef From fedora at leemhuis.info Wed Feb 22 20:59:22 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 22 Feb 2006 21:59:22 +0100 Subject: Unite Non-free repos (Was: Re: Non-free Extras?) In-Reply-To: <43FCC1D2.4020206@gmail.com> References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> <43FC1F67.7080607@argo.co.il> <20060222120630.GD20029@devserv.devel.redhat.com> <43FC5A1B.4070106@cornell.edu> <43FCC1D2.4020206@gmail.com> Message-ID: <1140641962.4192.102.camel@localhost.localdomain> Am Mittwoch, den 22.02.2006, 14:56 -0500 schrieb Eric Mesa: >[...] > The reason for my starting the thread was the fact that there are a > myriad of repos out there for those of us who need (or "need" - > depending on your point of view) access to non-free software. They > overlap in a lot of places, but some have one app that others don't. That's true. > However, mixing repos who don't work together can have bad results. Yep. > So I was hoping we could unite them in, Well, "unite them" sounds like a good plan -- the current situation creates a lot of confusing. Some users wandered off to Ubuntu due to that. But there are some things that you can't unite. So it probably needs to be a "unite what can be united". At least freshrpms and livna are close together regarding politics and packages -- both do not replace or update packages from Core or Extras (normally). Maybe it's time to forget all the old flamewars that happened years ago and merge the two. Anvil, thias, what's your opinion? I'm, willing to act as middle man for "merging discussions" if those two accept me (Disclaimer: I contribute to livna, but I was not involved in the flamewars in the pre-fedora.us days -- only some of those that happened later). newrpms: che has a package under review from extras. He also does not replace things from extras or livna normally. I'm optimistic that we could get him involved in merge plans, too. atrpms and dag/dries/rpmforge: Depends on them. They currently replace packages from Core and Extras -- that's necessary to achieve some things they do (things Extras and Livna don't do), but a lot of people don't like that. But there is no reason why they can't joins a merged "Non-Free-Repo" (Let's call it "Repo-Which-Must-Not-Be-Named") and continue the other stuff that does not harmonizes separately. But that's probably more work for them with a small gain for them. Correct me if I'm wrong. I didn't follow the other repos to closely -- maybe someone else can comment on those? >say, the Fedora-non-free and > Fedora-tricky-licensing repos so that they could work together and > maintain package consistency, etc. We probably can't do the above (and shouldn't do that) under the name "Fedora". Proprietary software (like the drivers from ati and nvidia) and "Patent Encumbered" software is a no go for Fedora afaics. But yes, maybe we could to a "Fedora Extras Non-Free" for things like - the Firmware for ipw2100 and ipw2200 - stuff like povray -- open-source, but not "free" (see https://www.redhat.com/archives/fedora-extras-list/2006-February/msg00191.html for details) CU thl -- Thorsten Leemhuis From nmiell at comcast.net Wed Feb 22 21:02:00 2006 From: nmiell at comcast.net (Nicholas Miell) Date: Wed, 22 Feb 2006 13:02:00 -0800 Subject: libstdc++-so7 info? In-Reply-To: <20060222201844.GF24295@devserv.devel.redhat.com> References: <20060222120933.GZ24295@devserv.devel.redhat.com> <1140637220.2983.4.camel@entropy> <20060222201844.GF24295@devserv.devel.redhat.com> Message-ID: <1140642120.2983.14.camel@entropy> On Wed, 2006-02-22 at 15:18 -0500, Jakub Jelinek wrote: > On Wed, Feb 22, 2006 at 11:40:20AM -0800, Nicholas Miell wrote: > > On Wed, 2006-02-22 at 07:09 -0500, Jakub Jelinek wrote: > > > On Wed, Feb 22, 2006 at 07:06:45AM -0500, Neal Becker wrote: > > > > I noticed the libstdc++-so7 preview, but I haven't been able to find any > > > > information that summarizes what is new, compared with the current > > > > libstdc++. Any pointers? > > > > > > It is only included for scim purposes, please don't use it for anything > > > else. It contains various ABI breaking experimental STL changes that > > > are not applicable to libstdc++.so.6. > > > > > > > Oh great, they're breaking the ABI again!? When will those idiots > > learn... > > > > How about Fedora stops including all new versions of libstdc++ until the > > maintainers manage to wrap their tiny little minds around the concept of > > a "stable ABI"? > > Please don't insult people who know about C++ ABI stuff far more than > you apparently do. Yeah, that was kind of harsh. This is one of my pet peeves. > There are several C++ ABI bugs both on the compiler > side (things you currently get with -fabi-version=0, PR22488 etc.) > and several things in the STL land are simply not doable without > ABI break, backwards compatibility in C++ world is a few orders of magnitude > harder in C++ than in C. G++ 3.4/4.0/4.1 have C++ ABI compatibility > and nobody said yet to my knowledge if 4.2 will or won't be compatible, > libstdc++so7 is simply a playground for things that aren't doable > without ABI break (similarly to -fabi-version=0). If/when it is decided > to do an ABI break, all the stuff in there can be used. > > >From my own experience when I was doing the long double switch also in > libstdc++, aiming for libstdc++.so.6 compatibility with both DFmode > and TFmode long double, maintaining C++ ABI compatibility is a nightmare, > you basically can't use symbol versioning and due to inheritance, inlining > and ODR things are really hard to do. > > We included this in Fedora, because SCIM IM modules are written in C++ > and as they need to be loaded into arbitrary Gtk (and KDE) applications, > there is a big problem if the application uses some older libstdc++.so. > This can be solved only with dlmopen (but then, SCIM IM modules us > like 40 or 50 shared library dependencies, so dlmopen isn't really a > good idea), or by namespace versioning, which is one of the things > libstdc++so7 has. Nice to see that somebody is finally trying to solve the problem, instead of just letting the users suffer. Maybe C++ will actually be a viable language for library development one day soon. (Also re: dlmopen & namespace versioning -- couldn't the same thing be accomplished using linker groups? -- assuming glibc supported them) -- Nicholas Miell From clumens at redhat.com Wed Feb 22 21:19:08 2006 From: clumens at redhat.com (Chris Lumens) Date: Wed, 22 Feb 2006 16:19:08 -0500 Subject: Rawhide kickstart install did not exclude packages In-Reply-To: References: <438244C3.5030700@cora.nwra.com> <20051121221436.GA5832@exeter.boston.redhat.com> Message-ID: <20060222211907.GD17260@exeter.boston.redhat.com> > Anything further on this? Here we are at FC5 test 3 and still no > package exclusions or inclusions get written into the generated > kickstart file during installation. Groups and included packages should be getting written. If not, please file a bug about it. - Chris From tjb at unh.edu Wed Feb 22 21:29:09 2006 From: tjb at unh.edu (Thomas J. Baker) Date: Wed, 22 Feb 2006 16:29:09 -0500 Subject: Logging out of gnome session almost always hangs Message-ID: <1140643749.5449.3.camel@zero.sr.unh.edu> Does anyone else suffer from the fact that almost every time I log out, the gnome desktop hangs with just the background showing? Going to a console and looking at the running processes includes gnome-session, gnome-panel, and lots of applets. I'd file a bug but I'm not sure what component to file it against. 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 admin at ramshacklestudios.com Wed Feb 22 21:36:08 2006 From: admin at ramshacklestudios.com (Peter Gordon) Date: Wed, 22 Feb 2006 13:36:08 -0800 (PST) Subject: Non-free Extras? In-Reply-To: <43FC5A1B.4070106@cornell.edu> References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> <43FC1F67.7080607@argo.co.il> <20060222120630.GD20029@devserv.devel.redhat.com> <43FC5A1B.4070106@cornell.edu> Message-ID: <43993.127.0.0.1.1140644168.squirrel@www.ramshacklestudios.com> Ivan Gyurdiev said: > For the moment I haven't heard of an OSS solution with good performance > for 3D games.... My Radeon 9200 works just wonderfully using the Free R200 DRI stack. (Then again, I'm not much for heavily graphics-intensive games anyhoo, except for the occasional match of Nexuiz with my friends.) ~~Peter From pjones at redhat.com Wed Feb 22 21:38:41 2006 From: pjones at redhat.com (Peter Jones) Date: Wed, 22 Feb 2006 16:38:41 -0500 Subject: FC5 test3 -- dmraid broken? In-Reply-To: <1140637356.22131.8.camel@localhost.localdomain> References: <1140499892.3430.13.camel@mentorng.gurulabs.com> <1140536181.20618.2.camel@localhost.localdomain> <1140587745.3551.20.camel@mentorng.gurulabs.com> <1140617913.22131.5.camel@localhost.localdomain> <1140626948.4113.18.camel@mentorng.gurulabs.com> <1140637356.22131.8.camel@localhost.localdomain> Message-ID: <1140644322.22131.10.camel@localhost.localdomain> On Wed, 2006-02-22 at 14:42 -0500, Peter Jones wrote: > Hrm. OK, that means it got farther. So try booting into the rescue > environment and adding those drives into the lvm filters, and I'll try > to figure out how to reproduce the failure. Actually, I think I see what's going wrong, and this won't help at all. -- Peter From igorm5 at vip.hr Wed Feb 22 21:41:21 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Wed, 22 Feb 2006 22:41:21 +0100 Subject: Ralink rt2500, can't load module In-Reply-To: <1140591640.2284.13.camel@aurora.localdomain> References: <43FB7DC9.8060307@vip.hr> <1140559789.3082.37.camel@laptopd505.fenrus.org> <1140591640.2284.13.camel@aurora.localdomain> Message-ID: <43FCDA81.80703@vip.hr> Trever L. Adams wrote: > This is a bug in rt2500. I reported it. It has to do with module_param > call not following the new standard. They have not fixed this problem > even though I reported it with a fix. I patched my own but am no longer > using the card (though when master mode works I will switch back due to > my preference for completely open source drivers instead of partially > one way or the other. > I suggest you ask them to fix it up for newer kernels. The problem is in > their MODULE_PARAM calls. http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?p=6906 I got some patch (php script) which I don't know how to apply :-/ Or it does not work for me, I don't know. I hope they will fix that very soon because FC5 is scheduled for 15th of March, which is very soon. I don't want to get stuck on FC4 because of this. -- Igor Jagec From eric.tanguy at univ-nantes.fr Wed Feb 22 21:44:35 2006 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Wed, 22 Feb 2006 22:44:35 +0100 Subject: Ralink rt2500, can't load module In-Reply-To: <1140591640.2284.13.camel@aurora.localdomain> References: <43FB7DC9.8060307@vip.hr> <1140559789.3082.37.camel@laptopd505.fenrus.org> <1140591640.2284.13.camel@aurora.localdomain> Message-ID: <1140644675.3119.4.camel@bureau.maison> Le mercredi 22 f?vrier 2006 ? 00:00 -0700, Trever L. Adams a ?crit : > This is a bug in rt2500. I reported it. It has to do with module_param > call not following the new standard. They have not fixed this problem > even though I reported it with a fix. I patched my own but am no longer > using the card (though when master mode works I will switch back due to > my preference for completely open source drivers instead of partially > one way or the other. > > I suggest you ask them to fix it up for newer kernels. The problem is in > their MODULE_PARAM calls. > > Trever > > On Tue, 2006-02-21 at 23:09 +0100, Arjan van de Ven wrote: > > On Tue, 2006-02-21 at 21:53 +0100, Igor Jagec wrote: > > > I compiled beta3 and cvs drivers on FC5t3 and everything went ok, but > > > the rt2500 module can't be loaded. On FC5t2's default kernel everything > > > went ok (both, compiling and loading the rt2500 module). > > > > > > [root at localhost Module]# /sbin/modprobe rt2500 > > > FATAL: Error inserting rt2500 > > > (/lib/modules/2.6.15-1.1955_FC5/extra/rt2500.ko): Invalid argument > > > > look in dmesg output for a more descriptive reason for the failure > > > -- > "He who chops his own wood, is warm twice." -- Abraham Lincoln > This is the report you speak about ? http://sourceforge.net/tracker/index.php?func=detail&aid=1427910&group_id=107832&atid=648846 If yes could you answer questions asked for the final submission ? If not could you give us the link to the report you did, please ? Thanks Eric From jos at xos.nl Wed Feb 22 21:50:50 2006 From: jos at xos.nl (Jos Vos) Date: Wed, 22 Feb 2006 22:50:50 +0100 Subject: relocatable rpm .spec question In-Reply-To: <43FCB678.8030102@research.att.com>; from ellson@research.att.com on Wed, Feb 22, 2006 at 02:07:36PM -0500 References: <43FCB678.8030102@research.att.com> Message-ID: <20060222225050.A12476@xos037.xos.nl> On Wed, Feb 22, 2006 at 02:07:36PM -0500, John Ellson wrote: > But I have a %post containing "%{_bindir}/foo" that isn't getting > relocated properly. > Its still looking for /usr/bin/foo instead of /home/ellson/usr/bin/foo. > > I tried "%{prefix}/bin/foo" but it still resolves to /usr/bin/foo All %{...} macros are evaluated at RPM build time, so this won't work. > Is there a variable set by the --prefix option that I can use in %post ? Yes, environment variables. Using $RPM_INSTALL_PREFIX0 for the (first) prefix should work. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From lamont at gurulabs.com Wed Feb 22 22:00:59 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Wed, 22 Feb 2006 15:00:59 -0700 Subject: Non-free Extras? In-Reply-To: <43993.127.0.0.1.1140644168.squirrel@www.ramshacklestudios.com> References: <43FBA1CD.4020908@gmail.com> <43FC5A1B.4070106@cornell.edu> <43993.127.0.0.1.1140644168.squirrel@www.ramshacklestudios.com> Message-ID: <200602221501.04106.lamont@gurulabs.com> On Wednesday 22 February 2006 02:36pm, Peter Gordon wrote: > Ivan Gyurdiev said: > > For the moment I haven't heard of an OSS solution with good performance > > for 3D games.... > > My Radeon 9200 works just wonderfully using the Free R200 DRI stack. (Then > again, I'm not much for heavily graphics-intensive games anyhoo, except > for the occasional match of Nexuiz with my friends.) The R200 driver has nothing in common with the R300 except for the similarity in name. The R200 is older and considered stable, IIRC. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From ivg2 at cornell.edu Wed Feb 22 22:07:46 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Wed, 22 Feb 2006 17:07:46 -0500 Subject: Non-free Extras? In-Reply-To: <43993.127.0.0.1.1140644168.squirrel@www.ramshacklestudios.com> References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> <43FC1F67.7080607@argo.co.il> <20060222120630.GD20029@devserv.devel.redhat.com> <43FC5A1B.4070106@cornell.edu> <43993.127.0.0.1.1140644168.squirrel@www.ramshacklestudios.com> Message-ID: <43FCE0B2.7070503@cornell.edu> >> For the moment I haven't heard of an OSS solution with good performance >> for 3D games.... >> > > My Radeon 9200 works just wonderfully using the Free R200 DRI stack. (Then > again, I'm not much for heavily graphics-intensive games anyhoo, except > for the occasional match of Nexuiz with my friends. > I am not very impressed with the benchmarks for this particular card (I am looking at 9200 SE 128). It appears to be in the same class as an Nvidia GeForce 5200 FX. My previous generation card was a 5700 FX Ultra, which at this point I consider obsolete, since it can't run any of the latest games without significant lag. Btw, I didn't know about this game... but it appears to suffer from the same stuttering bug as Doom3 and Quake4 out of the box - will investigate and file a bugzilla. =============== The point of my message was that people using non-free software for certain things have a good reason for doing so - they don't have too many alternative options. I would certainly prefer an OSS solution, but since I can't seem to find one, using what's available is the only course of action that makes sense. Pointing out how much better a free solution would be if it existed is not helpful - it would be when there's real choice available. In the meantime, I think it would be in everyone's benefit if oss could coexist with proprietary solutions. Anyway, this thread is getting off-topic, so... From rms at 1407.org Wed Feb 22 21:19:42 2006 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Wed, 22 Feb 2006 21:19:42 +0000 Subject: Non-free Extras? In-Reply-To: <43FC5A1B.4070106@cornell.edu> References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> <43FC1F67.7080607@argo.co.il> <20060222120630.GD20029@devserv.devel.redhat.com> <43FC5A1B.4070106@cornell.edu> Message-ID: <1140643182.6367.18.camel@localhost.localdomain> On Wed, 2006-02-22 at 07:33 -0500, Ivan Gyurdiev wrote: > Right... but since I don't want the debug anything, and my system is > stable, I don't pay a terrible price. > [if (false) => x] is true. The system could destabilize in the future, > at which point I'll re-evaluate my use of Nvidia cards. Actually, some time ago nVidia took a terribly long time (several months) to adapt to some Linux changes. Meanwhile, security bugs or 3D games... ah the choices of life... > Speaking of which, the nv driver is rather unstable, and does not work > for me at the moment - just filed a bug... Good for you. If you can't code the fix, at least give proper data to help solve it! Rui -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Wed Feb 22 22:30:06 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 22 Feb 2006 23:30:06 +0100 Subject: Non-free Extras? In-Reply-To: <43FCE0B2.7070503@cornell.edu> References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> <43FC1F67.7080607@argo.co.il> <20060222120630.GD20029@devserv.devel.redhat.com> <43FC5A1B.4070106@cornell.edu> <43993.127.0.0.1.1140644168.squirrel@www.ramshacklestudios.com> <43FCE0B2.7070503@cornell.edu> Message-ID: <43FCE5EE.5010100@hhs.nl> Ivan Gyurdiev wrote: > >>> For the moment I haven't heard of an OSS solution with good performance >>> for 3D games.... >>> >> >> My Radeon 9200 works just wonderfully using the Free R200 DRI stack. >> (Then >> again, I'm not much for heavily graphics-intensive games anyhoo, except >> for the occasional match of Nexuiz with my friends. >> > I am not very impressed with the benchmarks for this particular card (I > am looking at 9200 SE 128). > It appears to be in the same class as an Nvidia GeForce 5200 FX. My > previous generation card was a 5700 FX Ultra, which at this point I > consider obsolete, since it can't run any of the latest games without > significant lag. > The SE is a very bad choice it only has a 64 bit wide memory bus making it severly crippled. If you want to judge the 9200's judge a real one. Regards, Hans From alan at balclutha.org Wed Feb 22 22:38:52 2006 From: alan at balclutha.org (Alan Milligan) Date: Thu, 23 Feb 2006 09:38:52 +1100 Subject: Multiple concurrent versions of Python Message-ID: <43FCE7FC.1070302@balclutha.org> Guyz, Zope 2.8.5 and greater support Python 2.4 officially. Zope-2.9.x and Zope 3 actually *require* it. Plone's dependency chain is a little more complex. Adventurous people are running it on Zope-2.9, although I'd not recommend it. The 2.5 series of Plone will run on CMF-2.x which will definitely run on Zope-2.9, I'm not sure if there are issues with a 2.8.x port of this. We have an extensive set of Zope and Plone RPM's at https://linux.last-bastion.net/RPC2/up2date/plope, but we've not received much interest from any of the major Zope/Plone ISV's. There is presently a community push into egg territory, which is rather an anathema for RPM packagers. I'd absolutely not recommend attempting to package a lot of this stuff unless you actually intend to hang out on zope-dev and/or plone-dev as these are rather nuanced fast-moving targets. Alan From dlutter at redhat.com Wed Feb 22 23:23:43 2006 From: dlutter at redhat.com (David Lutterkort) Date: Wed, 22 Feb 2006 15:23:43 -0800 Subject: Unite Non-free repos (Was: Re: Non-free Extras?) In-Reply-To: <1140641962.4192.102.camel@localhost.localdomain> References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> <43FC1F67.7080607@argo.co.il> <20060222120630.GD20029@devserv.devel.redhat.com> <43FC5A1B.4070106@cornell.edu> <43FCC1D2.4020206@gmail.com> <1140641962.4192.102.camel@localhost.localdomain> Message-ID: <1140650623.13529.1.camel@currant.watzmann.net> On Wed, 2006-02-22 at 21:59 +0100, Thorsten Leemhuis wrote: > Well, "unite them" sounds like a good plan -- the current situation > creates a lot of confusing. Some users wandered off to Ubuntu due to > that. But there are some things that you can't unite. So it probably > needs to be a "unite what can be united". I think much could be gained, especially for users new to Fedora, if there was a page that describes what repos are available and why you would want to use each of them (and what to look out for if you use them) Does anybody want to add such a page to the Wiki ? David From sundaram at fedoraproject.org Wed Feb 22 23:28:41 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 23 Feb 2006 04:58:41 +0530 Subject: Unite Non-free repos (Was: Re: Non-free Extras?) In-Reply-To: <1140650623.13529.1.camel@currant.watzmann.net> References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> <43FC1F67.7080607@argo.co.il> <20060222120630.GD20029@devserv.devel.redhat.com> <43FC5A1B.4070106@cornell.edu> <43FCC1D2.4020206@gmail.com> <1140641962.4192.102.camel@localhost.localdomain> <1140650623.13529.1.camel@currant.watzmann.net> Message-ID: <43FCF3A9.10606@fedoraproject.org> David Lutterkort wrote: >On Wed, 2006-02-22 at 21:59 +0100, Thorsten Leemhuis wrote: > > >>Well, "unite them" sounds like a good plan -- the current situation >>creates a lot of confusing. Some users wandered off to Ubuntu due to >>that. But there are some things that you can't unite. So it probably >>needs to be a "unite what can be united". >> >> > >I think much could be gained, especially for users new to Fedora, if >there was a page that describes what repos are available and why you >would want to use each of them (and what to look out for if you use >them) > >Does anybody want to add such a page to the Wiki ? > > > We dont do that. http://fedoraproject.org/wiki/WikiEditing -- Rahul From jspaleta at gmail.com Wed Feb 22 23:33:24 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 22 Feb 2006 18:33:24 -0500 Subject: Unite Non-free repos (Was: Re: Non-free Extras?) In-Reply-To: <1140650623.13529.1.camel@currant.watzmann.net> References: <43FBA1CD.4020908@gmail.com> <43FC1F67.7080607@argo.co.il> <20060222120630.GD20029@devserv.devel.redhat.com> <43FC5A1B.4070106@cornell.edu> <43FCC1D2.4020206@gmail.com> <1140641962.4192.102.camel@localhost.localdomain> <1140650623.13529.1.camel@currant.watzmann.net> Message-ID: <604aa7910602221533s5ab3d55bu4218d806239d1481@mail.gmail.com> On 2/22/06, David Lutterkort wrote: > Does anybody want to add such a page to the Wiki ? I can think over two very good reasons to not to attempt this.. nor for the Fedora Project to allow this 1) Contributory infringement You can not say "go to this url to get the specific crap we can't provide ourselves" legally. http://www.fedoraproject.org/wiki/ForbiddenItems 2) Personal bias which could be misconstrued as project bias There are a variety of opinions as to which 3rd party repositories should be used and how they should be used. I think it absolutely unwise to encode personal bias as to "why you would want to use them" into the wiki that is meant to describe the Fedora Project. -jef"you might as well revoke my editting rights in the wiki right now.. because i will most likely replace any personal opinions expressed on that wikipage with my own..repeatedly"spaleta From michael.favia at insitesinc.com Thu Feb 23 00:03:47 2006 From: michael.favia at insitesinc.com (Michael Favia) Date: Wed, 22 Feb 2006 18:03:47 -0600 Subject: Ralink rt2500, can't load module In-Reply-To: <43FCDA81.80703@vip.hr> References: <43FB7DC9.8060307@vip.hr> <1140559789.3082.37.camel@laptopd505.fenrus.org> <1140591640.2284.13.camel@aurora.localdomain> <43FCDA81.80703@vip.hr> Message-ID: <43FCFBE3.9030801@insitesinc.com> Igor Jagec wrote: > Trever L. Adams wrote: > >> This is a bug in rt2500. I reported it. It has to do with module_param >> call not following the new standard. They have not fixed this problem >> even though I reported it with a fix. I patched my own but am no longer >> using the card (though when master mode works I will switch back due to >> my preference for completely open source drivers instead of partially >> one way or the other. >> I suggest you ask them to fix it up for newer kernels. The problem is in >> their MODULE_PARAM calls. > > http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?p=6906 > > I got some patch (php script) which I don't know how to apply :-/ Or it > does not work for me, I don't know. I hope they will fix that very soon > because FC5 is scheduled for 15th of March, which is very soon. I don't > want to get stuck on FC4 because of this. > I saw your patch and tried to apply it. It was able to build but failed to insert the module. I updated to fresh CVS this afternoon and I had '/var/log/message' complaints on the ifname parameter sections (when modprobe'd) so i just commented out lines 61 and 62 also removed the ifname option line from /etc/modules.conf. Obviously not the preferred solution but i am at least on the internet on this testing machine. -mf -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com From ellson at research.att.com Thu Feb 23 00:05:36 2006 From: ellson at research.att.com (John Ellson) Date: Wed, 22 Feb 2006 19:05:36 -0500 Subject: relocatable rpm .spec question In-Reply-To: <20060222225050.A12476@xos037.xos.nl> References: <43FCB678.8030102@research.att.com> <20060222225050.A12476@xos037.xos.nl> Message-ID: <43FCFC50.5050209@research.att.com> Jos Vos wrote: > On Wed, Feb 22, 2006 at 02:07:36PM -0500, John Ellson wrote: > > >> But I have a %post containing "%{_bindir}/foo" that isn't getting >> relocated properly. >> Its still looking for /usr/bin/foo instead of /home/ellson/usr/bin/foo. >> >> I tried "%{prefix}/bin/foo" but it still resolves to /usr/bin/foo >> > > All %{...} macros are evaluated at RPM build time, so this won't work. > > >> Is there a variable set by the --prefix option that I can use in %post ? >> > > Yes, environment variables. Using $RPM_INSTALL_PREFIX0 for the (first) > prefix should work. > > Thanks. Thats helped a bit. Where can I find a list of these variables? Is there one that will tell me if its lib or lib64 in %_libdir ? John From toshio at tiki-lounge.com Thu Feb 23 00:22:17 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 22 Feb 2006 16:22:17 -0800 Subject: Multiple concurrent versions of Python In-Reply-To: <43FCE7FC.1070302@balclutha.org> References: <43FCE7FC.1070302@balclutha.org> Message-ID: <1140654137.7261.14.camel@localhost> On Thu, 2006-02-23 at 09:38 +1100, Alan Milligan wrote: > Guyz, > > Zope 2.8.5 and greater support Python 2.4 officially. Zope-2.9.x and > Zope 3 actually *require* it. > From: http://www.zope.org/Products/Zope/2.8.5/Zope-2_8_5-released ''' At this time the only supported and recommended Python versions are 2.3.4 and 2.3.5. Using Python 2.4.X is not supported and not recommended at this time. [...] This warning also applies to binary packages that install Zope packages together with a system wide Python 2.4 installation (e.g. Fedora, SuSE...). ''' So from the outside looking in, zope-2.9.x is where python-2.4 compatibility starts. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From mharris at redhat.com Thu Feb 23 01:07:12 2006 From: mharris at redhat.com (Mike A. Harris) Date: Wed, 22 Feb 2006 20:07:12 -0500 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) Message-ID: <43FD0AC0.2090702@redhat.com> There have been a number of bugs reported in Red Hat bugzilla against X which have recently been tracked down to 3rd party video drivers being the culprit behind the problem the user was experienced. In many of the cases however, it wasn't obvious that the 3rd party drivers were at fault because the user was actually using the Red Hat supplied drivers, and not using the 3rd party driver that they had previously installed. Since I've wasted at least 6-8 hours in the last month diagnosing issues of this nature which have later turned out to be caused by proprietary drivers having been "installed" on the system, wether they were actually being *used* or not, I thought I should write a short useful informational email on the topic to the lists to try and inform people of some pitfalls you may encounter if you even _install_ 3rd party video drivers. Both ATI and Nvidia, and perhaps even other 3rd party drivers out there come in some form of tarball or equivalent form from the particular vendor. Most users seem to favour the hardware vendor supplied drivers directly, rather than using more sanely packaged 3rd party packages that contain the same drivers. This is very unfortunate, because installing these 3rd party tarball driver installations is very harmful to your clean OS installation. Both ATI and Nvidia's proprietary video driver installation utilities replace the Red Hat supplied libGL library with their own libGL. Nvidia's driver installs a replacement libglx.a X server module, removing the Red Hat supplied X.Org module in the process. ATI's driver may or may not replace libglx.a with it's own, I haven't checked (but if someone could confirm that, I'd appreciate knowing for certain). Once you have either of these drivers installed on your system, you can no longer use DRI with any video card. So if you install the ATI fglrx driver, while you should still be able in theory at least to use the Red Hat supplied radeon driver, you may no longer be able to use DRI with the radeon driver, because ATI's driver has blown away critical files that come with the OS that are needed for proper operation. If you install Nvidia's driver, and later decide to install an ATI card, and still have Nvidia's driver installed, bang - you will not be able to get Red Hat supplied DRI 3D acceleration to work. You must remove Nvidia's driver completely from your hard disk, and completely reinstall all of the xorg-x11 and mesa packages, and ensure they are all intact by using: rpm -Va Another problem being reported by a few people, is they are unable to get DRI to work because mesa libGL is looking for the DRI drivers in the wrong directory. The claim is that mesa is looking for the DRI drivers in /usr/X11R6/lib/modules. On a fresh OS install however, my findings are that mesa's libGL very much is not looking in /usr/X11R6 for it's modules. It is looking in the proper location of /usr/lib/dri for the modules. Why then is it looking in the wrong place on some systems? Answer: Because of fglrx having been installed. If you have had a previous OS release installed, and have installed ATI's fglrx driver from tarball, it has removed the OS supplied libGL et al and made backup copies of them aparently. Now you do an OS upgrade which works properly and installs everything in the right place. Then you uninstall ATI's fglrx with whatever script or whatever they supply, and now you try to run X, and get no DRI! Well, since you don't have fglrx installed at all, it must be our OS at fault right! Wrong. the uninstall script has put the OLD libGL it backed up (from FC4 or whatever) back in the system, overwriting the new FC5 supplied libGL in the process, and since ATI's fglrx driver is DRI based as well, it looks for the DRI modules in the wrong place now. Conclusions: If you are going to use any 3rd party proprietary drivers, please do yourself and everyone else a huge favour, and at least get your drivers from reputable 3rd party rpm package repositories such as livna.org which packages both the nvidia and ati proprietary drivers in rpm packages which install the drivers sanely without overwriting Red Hat/Fedora supplied files. These 3rd party packages install the files in alternative locations, and configure the X server et al. appropriately so that everything works. Since they do not blow away OS supplied files, you can use the OS supplied drivers still by reconfiguring xorg.conf. Also, if you decide to uninstall the 3rd party drivers via rpm, they just go away and cause no further harm to the system. So PLEASE USE THIRD PARTY RPM PACKAGES if you _must_ use 3rd party drivers. It helps create world peace. If you choose to install ATI or Nvidia tarball/whatever drivers directly from ATI/Nvidia (or any other vendor for that matter), your system is 100% completely and totally unsupported. Even if you are using _our_ drivers, your 3rd party driver installation may have blown away our libGL, our libglx.a or any other files that have been supplied by our OS. As such, your system is not supported. For those who encounter a bug of any kind whatsoever while using 3rd party video drivers, completely remove the 3rd party drivers from your system, and then perform a full "yum update" to ensure you have the latest Fedora Core supplied X packages installed. After doing this, do an "rpm -Va" of your whole system, in particular the xorg-x11-*, mesa-* and lib* packages. If there are any discrepancies found in any of the Fedora supplied packages, in particular in libGL, or the X server packages, remove them and reinstall them and reverify that the files installed on your system are the ones shipped by Fedora. If you are able to reproduce the problem you are having after having performed these steps, and having ensured that you are neither using 3rd party drivers, nor even have them installed, then feel free to file a bug report in bugzilla. By doing this small amount of pre-diagnosis of your own system if you are using 3rd party drivers, you will save yourself a lot of headaches, and will save other people, including developers such as myself from wasting endless hours trying to diagnose problems which turn out to be bogus. Hours which could have been spent fixing legitimate bugs that are present in bugzilla. As an additional note - if anyone is using proprietary drivers and has any problems which they believe might actually be a bug in Xorg and not in their proprietary driver - file such bugs directly in X.Org bugzilla. X.Org has an nVidia (closed) component specifically for the proprietary driver, and Nvidia engineers get those bugs and will investigate them over time. Anyhow, I hope this helps people understand at least some of the problems that can occur when you opt to using 3rd party drivers, present some alternatives, and to help people diagnose their own problems which might be caused by having installed 3rd party drivers. Thanks for reading. TTYL P.S. Feel free to forward this email on to any other lists or people whom you think might benefit from it. Also, if anyone thinks this information would be useful to have on the Fedora Wiki or somewhere else, feel free to copy my email into a wiki page, or paraphrase, etc. -- Mike A. Harris, Systems Engineer, X11 Development team, Red Hat Canada, Ltd. From benjy.grogan at gmail.com Thu Feb 23 01:23:22 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Wed, 22 Feb 2006 20:23:22 -0500 Subject: Non-free Extras? In-Reply-To: <20060222120630.GD20029@devserv.devel.redhat.com> References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> <43FC1F67.7080607@argo.co.il> <20060222120630.GD20029@devserv.devel.redhat.com> Message-ID: On 2/22/06, Alan Cox wrote: > > On Wed, Feb 22, 2006 at 05:03:52AM -0500, Benjy Grogan wrote: > > Is there a way of including proprietary drivers with the Fedora > Project? In > > time, Nvidia, ATI et al will definitely have the best available linux > > drivers for their hardware so it seems inevitable that proprietary > drivers > > will have to be included in Fedora. > > Fedora is free software. If you want to add proprietary software whether > that > is Nvidia drivers, Oracle or Quake 4 then its between you and the vendor. > The > Nvidia and Ati drivers are actually more tricky than the proprietary > applications to deal with because their legality is open to some dispute. > > > They're giving away their drivers for free anyways. > > Only in price, and then you pay a terrible price if you want to debug > anything > or your system isn't stable With all the myriad hardware out there the open source community cannot possibly develop drivers for everything. It seems to me that the open source community figures out the architecture, and the hardware goliaths develop their drivers within that architecture. Of course, it would be great if the hardware goliaths open sourced their drivers. Benjy -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndbecker2 at gmail.com Thu Feb 23 02:55:49 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 22 Feb 2006 21:55:49 -0500 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) References: <43FD0AC0.2090702@redhat.com> Message-ID: Speaking of DRI, I have an ATI 200M. Using clean install of xorg driver, I see this: (WW) RADEON(0): Enabling DRM support [...] drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device or address) [ repeat 255 times ...] (II) RADEON(0): [drm] drmOpen failed (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. I think I mentioned this here before, and IIRC someone else said they have exactly the same result. Is this expected behavior? /sbin/lsmod Module Size Used by radeon 141665 0 drm 117481 1 radeon drm is loaded, but there are no /dev/dri/ From naoki at valuecommerce.com Thu Feb 23 02:55:39 2006 From: naoki at valuecommerce.com (Naoki) Date: Thu, 23 Feb 2006 11:55:39 +0900 Subject: Xen issues - Was Xen network performance problem during kickstart. In-Reply-To: <20060221103132.GA9506@redhat.com> References: <1139987549.21111.68.camel@dragon.sys.intra> <1140052865.2302.64.camel@host-81-191-138-132.bluecom.no> <1140060379.21111.145.camel@dragon.sys.intra> <1140078535.4651.84.camel@dragon.sys.intra> <1140157902.3229.32.camel@dragon.sys.intra> <1140442863.3357.4.camel@orbit.scot.redhat.com> <1140451864.2384.81.camel@dragon.sys.intra> <1140508134.2384.126.camel@dragon.sys.intra> <20060221103132.GA9506@redhat.com> Message-ID: <1140663339.2870.6.camel@dragon.sys.intra> New bug :) Anybody else see this. I tried the same type of install as before expect this time thought I'd give it 512MB RAM instead of 256M. ------------[ cut here ]------------ kernel BUG at include/asm/xor.h:633! invalid opcode: 0000 [#1] SMP Modules linked in: xor raid1 raid0 xennet sr_mod sd_mod scsi_mod cdrom squashfs loop nfs nfs_acl lockd sunrpc vfat fat cramfs CPU: 0 EIP: 0061:[] Not tainted VLI EFLAGS: 00010246 (2.6.15-1.1975_FC5guest) EIP is at xor_sse_2+0x1de/0x1ec [xor] eax: 00000000 ebx: 00000000 ecx: 00000000 edx: dab8c000 next screen esi: dab89000 edi: 00000000 ebp: 00000000 esp: dab81de0 ds: 007b es: 007b ss: 0069 Process loader (pid: 145, threadinfo=dab80000 task=daffad30) Stack: <0>00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 e10bc5ac 00000000 e10b9b13 00001000 dab88000 dab8b000 dab8b000 dab88000 Call Trace: [] do_xor_speed+0x42/0x90 [xor] Traceback (most recent call last): File "/usr/bin/anaconda", line 1108, in ? from yuminstall import YumBackend File "/usr/lib/anaconda/yuminstall.py", line 427 if self.tsInfo.reqmedia = {}: ^ SyntaxError: invalid syntax From nicu_fedora at nicubunu.ro Thu Feb 23 06:57:50 2006 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Thu, 23 Feb 2006 08:57:50 +0200 Subject: Proposing a switch to Tango In-Reply-To: <1140630689.2107.10.camel@price.stavtrup-st.dk> References: <1140557623.24450.12.camel@price.stavtrup-st.dk> <1140628870.2464.42.camel@halflap> <1140630689.2107.10.camel@price.stavtrup-st.dk> Message-ID: <43FD5CEE.6000306@nicubunu.ro> David Nielsen wrote: > > Upstream is not looking to adopt Tango out of the fear that without > vendor support, it will look like a GNOME only project and thus scare > off the KDE crowd. Or so it seems. Thus vendor buy in is very important, I was thinking upstream (Gnome) is not looking to adopt Tango because it does not follow the HIG (icon sizes, colors, style). There is a conflict and I think a decision about Fedora switching to Tango better wait until this conflict is settled. -- nicu my hats collection: http://fedora.nicubunu.ro/hats/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From jos at xos.nl Thu Feb 23 07:22:29 2006 From: jos at xos.nl (Jos Vos) Date: Thu, 23 Feb 2006 08:22:29 +0100 Subject: relocatable rpm .spec question In-Reply-To: <43FCFC50.5050209@research.att.com>; from ellson@research.att.com on Wed, Feb 22, 2006 at 07:05:36PM -0500 References: <43FCB678.8030102@research.att.com> <20060222225050.A12476@xos037.xos.nl> <43FCFC50.5050209@research.att.com> Message-ID: <20060223082229.A14803@xos037.xos.nl> On Wed, Feb 22, 2006 at 07:05:36PM -0500, John Ellson wrote: > Where can I find a list of these variables? > > Is there one that will tell me if its lib or lib64 in %_libdir ? You don't need that (and thus they aren't available as env.vars in %post etc. scripts), because these are all static values (the prefix exmaple you gave is not static, as it can be specified at install time). For the others you can always add something like MYVAR=%_libdir in your %post script and use $MYVAR in your script. And if you want to see all environment variables, just create a dummy package and add "set > /tmp/rpm.vars" in %post and see what it gives ;-). -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From igorm5 at vip.hr Thu Feb 23 07:23:25 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Thu, 23 Feb 2006 08:23:25 +0100 Subject: Ralink rt2500, can't load module In-Reply-To: <43FCFBE3.9030801@insitesinc.com> References: <43FB7DC9.8060307@vip.hr> <1140559789.3082.37.camel@laptopd505.fenrus.org> <1140591640.2284.13.camel@aurora.localdomain> <43FCDA81.80703@vip.hr> <43FCFBE3.9030801@insitesinc.com> Message-ID: <43FD62ED.7070701@vip.hr> Michael Favia wrote: > Igor Jagec wrote: >>http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?p=6906 > I saw your patch and tried to apply it. It was able to build but failed > to insert the module. I updated to fresh CVS this afternoon and I had > '/var/log/message' complaints on the ifname parameter sections (when > modprobe'd) so i just commented out lines 61 and 62 also removed the In static_debug_parm.php file? > ifname option line from /etc/modules.conf. In /etc/modules.conf? Or /etc/modprobe.conf? > Obviously not the preferred > solution but i am at least on the internet on this testing machine. -mf The same problem here after I succesfully applied the patch. Could you copy/paste the lines 61 and 62 here? Is that it: // -extern int debug; ? Thanks. -- Igor Jagec From tadams-lists at myrealbox.com Thu Feb 23 08:00:26 2006 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Thu, 23 Feb 2006 01:00:26 -0700 Subject: Ralink rt2500, can't load module In-Reply-To: <1140644675.3119.4.camel@bureau.maison> References: <43FB7DC9.8060307@vip.hr> <1140559789.3082.37.camel@laptopd505.fenrus.org> <1140591640.2284.13.camel@aurora.localdomain> <1140644675.3119.4.camel@bureau.maison> Message-ID: <1140681626.4681.13.camel@aurora.localdomain> No, that is not it. I no longer have the book mark, but it was in the support forums (vichu is the user name). I cannot remember which team member was reading my comments. They fixed up the USB part but didn't fix up the module_param stuff. Basically, in newer kernels, this has changed and the latest one now has depricated the older method. instead of "i" or what not for type it is int. Beyond that, I cannot remember what the changes were. Trever On Wed, 2006-02-22 at 22:44 +0100, Eric Tanguy wrote: > Le mercredi 22 f?vrier 2006 ? 00:00 -0700, Trever L. Adams a ?crit : > > This is a bug in rt2500. I reported it. It has to do with module_param > > call not following the new standard. They have not fixed this problem > > even though I reported it with a fix. I patched my own but am no longer > > using the card (though when master mode works I will switch back due to > > my preference for completely open source drivers instead of partially > > one way or the other. > > > > I suggest you ask them to fix it up for newer kernels. The problem is in > > their MODULE_PARAM calls. > > > > Trever > > > > On Tue, 2006-02-21 at 23:09 +0100, Arjan van de Ven wrote: > > > On Tue, 2006-02-21 at 21:53 +0100, Igor Jagec wrote: > > > > I compiled beta3 and cvs drivers on FC5t3 and everything went ok, but > > > > the rt2500 module can't be loaded. On FC5t2's default kernel everything > > > > went ok (both, compiling and loading the rt2500 module). > > > > > > > > [root at localhost Module]# /sbin/modprobe rt2500 > > > > FATAL: Error inserting rt2500 > > > > (/lib/modules/2.6.15-1.1955_FC5/extra/rt2500.ko): Invalid argument > > > > > > look in dmesg output for a more descriptive reason for the failure > > > > > -- > > "He who chops his own wood, is warm twice." -- Abraham Lincoln > > > This is the report you speak about ? > http://sourceforge.net/tracker/index.php?func=detail&aid=1427910&group_id=107832&atid=648846 > If yes could you answer questions asked for the final submission ? > If not could you give us the link to the report you did, please ? > Thanks > Eric > > -- "Magazines all too frequently lead to books and should be regarded by the prudent as the heavy petting of literature." -- Fran Lebowitz From igorm5 at vip.hr Thu Feb 23 08:06:05 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Thu, 23 Feb 2006 09:06:05 +0100 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <43FD0AC0.2090702@redhat.com> References: <43FD0AC0.2090702@redhat.com> Message-ID: <43FD6CED.9040703@vip.hr> Mike A. Harris wrote: > Both ATI and Nvidia, and perhaps even other 3rd party drivers out there > come in some form of tarball or equivalent form from the particular > vendor. Most users seem to favour the hardware vendor supplied drivers > directly, rather than using more sanely packaged 3rd party packages that > contain the same drivers. This is very unfortunate, because installing > these 3rd party tarball driver installations is very harmful to your > clean OS installation. > Both ATI and Nvidia's proprietary video driver installation utilities > replace the Red Hat supplied libGL library with their own libGL. > Nvidia's driver installs a replacement libglx.a X server module, > removing the Red Hat supplied X.Org module in the process. ATI's > driver may or may not replace libglx.a with it's own, I haven't checked > (but if someone could confirm that, I'd appreciate knowing for certain). What if we uninstall the official nVidia tarball and install Livna nvidia package, do we back things in order? Or it takes some extra manual work? Speaking about libglx.a and stuff. I mean, there it would be insane if we had to reinstall the whole system because of that. Thanks. -- Igor Jagec From n0dalus+redhat at gmail.com Thu Feb 23 08:10:46 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Thu, 23 Feb 2006 18:40:46 +1030 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <43FD6CED.9040703@vip.hr> References: <43FD0AC0.2090702@redhat.com> <43FD6CED.9040703@vip.hr> Message-ID: <6280325c0602230010w7f46f8b0gc3592e14fb5b6ddb@mail.gmail.com> On 2/23/06, Igor Jagec wrote: > > What if we uninstall the official nVidia tarball and install Livna > nvidia package, do we back things in order? Or it takes some extra > manual work? Speaking about libglx.a and stuff. I mean, there it would > be insane if we had to reinstall the whole system because of that. Thanks. > Like Mike Harris said, > For those who encounter a bug of any kind whatsoever while using > 3rd party video drivers, completely remove the 3rd party drivers > from your system, and then perform a full "yum update" to ensure > you have the latest Fedora Core supplied X packages installed. After > doing this, do an "rpm -Va" of your whole system, in particular the > xorg-x11-*, mesa-* and lib* packages. If there are any discrepancies > found in any of the Fedora supplied packages, in particular in libGL, > or the X server packages, remove them and reinstall them and reverify > that the files installed on your system are the ones shipped by > Fedora. Essentially, after installing livna's packages instead, you would need to do an rpm -Va on various packages to ensure that the files hadn't been replaced (If they have, reinstall those packages). n0dalus. From jspaleta at gmail.com Thu Feb 23 08:13:56 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 23 Feb 2006 03:13:56 -0500 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <43FD6CED.9040703@vip.hr> References: <43FD0AC0.2090702@redhat.com> <43FD6CED.9040703@vip.hr> Message-ID: <604aa7910602230013h45d90f4bg7526ac0faaff041e@mail.gmail.com> On 2/23/06, Igor Jagec wrote: > What if we uninstall the official nVidia tarball and install Livna > nvidia package, do we back things in order? Or it takes some extra > manual work? If you ever install from the nvidia tarball.. you have to reinstall the Core mesa packages to make sure the Core mesa libraries are put back as expected. The livna packages prevent problems... they do not fix the problems caused by tarball based installs. The livna packages by design do not touch the library files owned by Core packages so they can not fix problems associated with vendor tarball installs overwriting those libraries. -jef From buildsys at redhat.com Thu Feb 23 08:21:39 2006 From: buildsys at redhat.com (Build System) Date: Thu, 23 Feb 2006 03:21:39 -0500 Subject: rawhide report: 20060223 changes Message-ID: <200602230821.k1N8LdZX004612@porkchop.devel.redhat.com> New package jakarta-commons-daemon Jakarta Commons Daemon Package Updated Packages: anaconda-10.92.8-1 ------------------ * Wed Feb 22 2006 David Cantrell 10.92.8-1 - Removed obsolete bogl code (katzj) - Removed unused code in upgrade.py (pnasrat) - Check version and packages to upgrade (pnasrat) - Removed old IDE RAID code from isys (katzj) - Various traceback fixes - Don't use underline in device names for hotkeys in bootloader gui (pjones) - Mount /selinux in rescue mode (katzj) aspell-12:0.60.3-4 ------------------ * Tue Feb 21 2006 Ivana Varekova - 12:0.60.3-4 - fix multilib file conflict * Fri Feb 10 2006 Jesse Keating - 12:0.60.3-3.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 12:0.60.3-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes at-spi-1.7.5-1 -------------- * Tue Feb 21 2006 Matthias Clasen - 1.7.5-1 - Update to 1.7.5 cpuspeed-1:1.2.1-1.32 --------------------- * Tue Feb 21 2006 Dave Jones - Missed another occurance of the same problem I fixed yesterday. * Mon Feb 20 2006 Dave Jones - Some ACPI BIOSes start counting CPUs at 0, some at 1. *sigh* (#181673) e2fsprogs-1.38-8 ---------------- * Wed Feb 22 2006 Peter Jones - 1.36-8 - handle selinux context on blkid.tab * Mon Feb 20 2006 Karsten Hopp 1.38-7 - BuildRequires: gettext-devel eog-2.13.91-2 ------------- * Wed Feb 15 2006 Matthias Clasen - 2.13.91-2 - silence excessive debug output f-spot-0.1.9-2 -------------- * Tue Feb 21 2006 Karsten Hopp 0.1.9-2 - add BuildRequires libgnome-devel libgnomeui-devel gtk2-devel mono-devel libjpeg-devel sqlite-devel * Fri Feb 17 2006 Christopher Aillon - 0.1.9-1 - Update to 0.1.9 gail-1.8.10-1 ------------- * Wed Feb 22 2006 Matthias Clasen - 1.8.10-1 - Update to 1.8.10 gdb-6.3.0.0-1.106 ----------------- * Tue Feb 14 2006 Alexandre Oliva - 6.3.0.0-1.106 - Bump up release number. * Tue Feb 14 2006 Alexandre Oliva - 6.3.0.0-1.103 - Adjust type-punning patch to include fix not needed upstream. * Tue Feb 14 2006 Alexandre Oliva - 6.3.0.0-1.102 - Bump up release number. gdm-1:2.13.0.8-4 ---------------- * Sun Feb 19 2006 Ray Strode - 1:2.13.0.8-3 - add server entry for accel-indirect branch of xorg * Wed Feb 15 2006 Ray and Matthias - 1:2.13.0.8-2 - malloc memory that is later freed gnome-applets-1:2.13.4-3 ------------------------ * Sat Feb 18 2006 Matthias Clasen - 2.13.4-3 - Remove a warning from the stock ticker applet gnome-power-manager-2.13.91-1 ----------------------------- * Tue Feb 21 2006 Matthias Clasen - 2.13.91-1 - Update to 2.13.91 - Drop upstreamed patch groff-1.18.1.1-10 ----------------- * Thu Feb 16 2006 Miroslav Lichvar - 1.18.1.1-10 - use mktemp for temporary files in pic2graph and eqn2graph scripts hal-0.5.7-0.cvs20060213.2 ------------------------- * Thu Feb 16 2006 Matthias Clasen - 0.5.7-0.cvs20060213.2 - fix directory ownership - don't ship static libraries * Mon Feb 13 2006 Jesse Keating - 0.5.7-0.cvs20060213.1.1 - rebump for build order issues during double-long bump hwdata-0.176-1 -------------- * Wed Feb 22 2006 Phil Knirsch - 0.176-1 - More entries from Dell to MonitorsDB (#181008) * Fri Feb 10 2006 Phil Knirsch - 0.175-1 - Added a few more entries to MonitorsDB jakarta-commons-digester-0:1.7-2jpp_9fc --------------------------------------- * Tue Feb 21 2006 Rafael Schloming - 0:1.7-2jpp_9fc - Updated to version 1.7. jakarta-commons-validator-0:1.1.4-1jpp_5fc ------------------------------------------ * Tue Feb 21 2006 Rafael Schloming - 0:1.1.4-1jpp_5fc - Updated to 1.1.4 and aot compiled. kdemultimedia-6:3.5.1-2 ----------------------- * Wed Feb 22 2006 Than Ngo 6:3.5.1-2 - add missing protocol audiocd #176637 - remove useless rpm macro #180009 - add requires on alsa-lib-devel #178734 kexec-tools-1.101-9 ------------------- * Wed Feb 22 2006 Thomas Graf - 1.101-9 - Remove wrong quotes around --command-line in kdump.init * Fri Feb 17 2006 Jeff Moyer - 1.101-8 - Fix the service stop case. It was previously unloading the wrong kernel. - Implement the "restart" function. - Add the "irqpoll" option as a default kdump kernel commandline parameter. - Create a default kernel command line in the sysconfig file upon rpm install. kudzu-1.2.32-1 -------------- * Wed Feb 22 2006 Bill Nottingham - 1.2.32-1 - fix potential segfault with USB network devices (#182006) logwatch-7.1-8 -------------- * Mon Feb 20 2006 Ivana Varekova 7.1-8 - fix http exploit problem #181802 lsof-4.76-2 ----------- * Wed Feb 15 2006 Karel Zak 4.76-2 - fix #175568 - lsof prints 'unknown inode type' for epoll mesa-6.4.2-4 ------------ * Wed Feb 22 2006 Adam Jackson 6.4.2-4 - rebuilt mkinitrd-5.0.27-1 ----------------- * Wed Feb 22 2006 Peter Jones - 5.0.27-1 - Fix multiboot argument quoting in new-kernel-package (#182243) - Fix "netlink" fd error in hotplug initialization. - Fix directory creation in smartmknod() - Fix find command when it's not run alone (#181874, patch from Mark McLoughlin) - Don't use 0-length uuids - Update /dev/mapper nodes more often - Allow dm partadd not to include the /dev/mapper path - Use /etc/fstab, not /fstab, so if you've got /sbin/mount it'll work - Bring in sd_mod if libata or scsi_mod is selected (#181983) - use -Wl,--wrap,open and __wrap_open() instead of coeOpen() parted-1.6.25-7 --------------- * Wed Feb 22 2006 Peter Jones - 1.6.25-7 - close /proc/devices correctly pirut-0.9.15-1 -------------- * Wed Feb 22 2006 Jeremy Katz - 0.9.15-1 - actually find the images * Wed Feb 22 2006 Jeremy Katz - 0.9.14-1 - fix traceback on right click (#182360) - add hal and dbus to pup's reboot list - new images from dfong - allow stopping the search, requires yum 2.5.3 psacct-6.3.2-39 --------------- * Mon Feb 20 2006 Ivana Varekova - 6.3.2-39 - add Large File Support python-pyblock-0.15-1 --------------------- * Wed Feb 22 2006 Peter Jones - 0.15-1 - Fix use of devices in /tmp to avoid duplicates. (fixes console spew during install) python-urlgrabber-2.9.8-1 ------------------------- * Wed Feb 22 2006 Jeremy Katz - 2.9.8-1 - update to new version fixing progress bars in yum on regets redhat-artwork-0.240-1 ---------------------- * Wed Feb 22 2006 Matthias Clasen - 0.240-1 - Include Serbian translations rhgb-0.16.3-1 ------------- * Wed Feb 22 2006 Matthias Clasen - 0.16.3-1 - don't include the (old, unused) Fedora logo rhpxl-0.17-1 ------------ * Wed Feb 22 2006 Jeremy Katz - 0.17-1 - fix braindead i810 (#182300) * Wed Feb 22 2006 Chris Lumens 0.16-1 - Only put one non-vesa card in front of the list (#182016). - Provide a fixed list of supported resolutions for the SGI 1600SW (#115679). sane-backends-1.0.17-4 ---------------------- * Wed Feb 22 2006 Nils Philippsen - 1.0.17-4 - split off generated documentation into separate subpackage to avoid conflicts on multilib systems selinux-policy-2.2.20-1 ----------------------- * Wed Feb 22 2006 Dan Walsh 2.2.20-1 - Fix load_policy to work on MLS - Fix cron_rw_system_pipes for postfix_postdrop_t - Allow audotmount to run showmount sendmail-8.13.5-3 ----------------- * Fri Feb 17 2006 Thomas Woerner 8.13.5-3 - fixed selinuxenabled path in initscript - fixed error handling with sigwait (#137709) Thanks to Jonathan Kamens for the patch - fixed prereq for cyrus-sasl: now using /usr/sbin/saslauthd - appended 'dnl' to cert tags in sendmail.mc struts-0:1.2.8-2jpp_8fc ----------------------- * Tue Feb 21 2006 Rafael Schloming - 0:1.2.8-2jpp_8fc - Updated to 1.2.8 tomboy-0.3.5-3 -------------- * Fri Feb 17 2006 Christopher Aillon - 0.3.5-3 - Don't run tomboy in the current working directory tzdata-2006b-1 -------------- * Wed Feb 22 2006 Petr Machata 2006b-1 - Upstream 2006b: - using tz64code version, as 32 is legacy according to tzdata ML - new manual pages for ctime, strftime, tzset - some source code reorganizations - no timezone/dst rule updates udev-084-4 ---------- * Wed Feb 22 2006 Harald Hoyer - 084-4 - fixed group issue with vol_id (bz #181432) - fixed dvb permissions (bz #179993) - added support for scsi media changer (bz #181911) - fixed pktcdvd device creation (bz #161268) * Tue Feb 21 2006 Florian La Roche - 084-3 - also output the additional space char as part of the startup message vim-1:6.4.007-2 --------------- * Mon Feb 20 2006 Karsten Hopp 6.4.007-2 - gtk-update-icon-cache --ignore-theme-index (avoids %post failures when hicolor-icon-theme isn't installed) vixie-cron-4:4.1-54.FC5 ----------------------- * Wed Feb 15 2006 Jason Vas Dias - 4:4.1-54.FC5 - fix bug 181702: Requires:audit-libs, not Requires:audit xerces-j2-0:2.7.1-6jpp_6fc -------------------------- * Wed Feb 22 2006 Rafael Schloming - 0:2.7.1-6jpp_6fc - Updated to 2.7.1 xml-commons-0:1.3.02-0.b2.7jpp_6fc ---------------------------------- * Wed Feb 22 2006 Rafael Schloming - 0:1.3.02-0.b2.7jpp_6fc - Updated to 1.3 xorg-x11-drv-glint-1.0.1.3-2 ---------------------------- * Wed Feb 22 2006 Mike A. Harris 1.0.1.3-2 - Install glint.xinf, which was inadvertently left out of packaging (#182502) * Tue Feb 07 2006 Jesse Keating 1.0.1.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Wed Jan 18 2006 Mike A. Harris 1.0.1.3-1 - Updated xorg-x11-drv-glint to version 1.0.1.3 from X11R7.0 xorg-x11-drv-i740-1.0.0.5-2 --------------------------- * Wed Feb 22 2006 Mike A. Harris 1.0.0.5-2 - Install i740.xinf, which was inadvertently left out of packaging (#182503) * Tue Feb 07 2006 Jesse Keating 1.0.0.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Wed Jan 18 2006 Mike A. Harris 1.0.0.5-1 - Updated xorg-x11-drv-i740 to version 1.0.0.5 from X11R7.0 xorg-x11-drv-s3-0.3.5.5-2 ------------------------- * Wed Feb 22 2006 Mike A. Harris 0.3.5.5-2 - Install s3.xinf, which was inadvertently left out of packaging (#182505) * Fri Feb 10 2006 Jesse Keating 0.3.5.5-1.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating 0.3.5.5-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-via-0.1.33.2-2 --------------------------- * Wed Feb 22 2006 Mike A. Harris 0.1.33.2-2 - Install via.xinf, which was inadvertently left out of packaging (#182506) * Tue Feb 07 2006 Jesse Keating 0.1.33.2-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Wed Jan 18 2006 Mike A. Harris 0.1.33.2-1 - Updated xorg-x11-drv-via to version 0.1.33.2 from X11R7.0 xorg-x11-font-utils-1:1.0.1-3 ----------------------------- * Wed Feb 22 2006 Mike A. Harris 1:1.0.1-3 - Remove "Obsoletes: xorg-x11-font-utils" as the package should not obsolete itself. Leftover from the original package template it seems. (#182439) xorg-x11-proto-devel-7.0-5 -------------------------- * Wed Feb 22 2006 Jeremy Katz - 7.0-5 - require mesa-libGL-devel since it's needed by some of the headers xorg-x11-server-1.0.1-7 ----------------------- * Wed Feb 22 2006 Jeremy Katz - 1.0.1-7 - install randrstr.h as part of sdk as required for building some drivers * Tue Feb 21 2006 Mike A. Harris - Added xorg-server-1.0.1-backtrace.patch which enables the Xorg server's built in backtrace support by default, as it was inadvertently disabled in 7.0. * Fri Feb 10 2006 Jesse Keating 1.0.1-6.1 - bump again for double-long bug on ppc(64) xterm-209-2 ----------- * Wed Feb 22 2006 Jason Vas Dias - 209-2 - fix bug 182382: check for (VWindow(screen)!=0) in set_cursor_gcs - further fix for bug 178302: allow *vt100*cursorColor to be same as fg yum-2.5.3-1 ----------- * Wed Feb 22 2006 Jeremy Katz - 2.5.3-1 - Update to 2.5.3 with fixes for lots of stuff (and all of our patches applied) (#177528, #177737, #179512, others) Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15-5.FC5.4.i686 requires kernel = 0:2.6.15-1.1955_FC5 GFS-kernel - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5 GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5smp cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp gnbd-kernel - 2.6.15-5.FC5.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.i386 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.i386 requires tomcat4 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.ia64 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.ia64 requires tomcat4 vconfig - 1.9-1.1.ia64 requires libc.so.6 vconfig - 1.9-1.1.ia64 requires libc.so.6(GLIBC_2.0) Broken deps for ppc ---------------------------------------------------------- struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.ppc requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.ppc requires tomcat4 Broken deps for ppc64 ---------------------------------------------------------- emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.ppc64 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.ppc64 requires tomcat4 vconfig - 1.9-1.1.ppc64 requires libc.so.6 vconfig - 1.9-1.1.ppc64 requires libc.so.6(GLIBC_2.0) Broken deps for s390 ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.s390 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.s390 requires tomcat4 Broken deps for s390x ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.s390x requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.s390x requires tomcat4 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.x86_64 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.x86_64 requires tomcat4 From tajesudoss1 at yahoo.com Thu Feb 23 08:44:33 2006 From: tajesudoss1 at yahoo.com (jesu doss) Date: Thu, 23 Feb 2006 00:44:33 -0800 (PST) Subject: (no subject) Message-ID: <20060223084433.78119.qmail@web54108.mail.yahoo.com> --------------------------------- Brings words and photos together (easily) with PhotoMail - it's free and works with Yahoo! Mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan at balclutha.org Thu Feb 23 08:48:44 2006 From: alan at balclutha.org (Alan Milligan) Date: Thu, 23 Feb 2006 19:48:44 +1100 Subject: Multiple concurrent versions of Python Message-ID: <43FD76EC.70807@balclutha.org> Toshio Kuratomi wrote: > So from the outside looking in, zope-2.9.x is where python-2.4 > compatibility starts. > I've been making contributions to the Zope project for about four years now, and follow it very closely. If you'd cared to look in the Zope dev archives, you'd have seen posts from me regarding exactly this issue for perhaps 8 months now. As per the discussions of my post about this a few months ago, Jim Fulton and Andreas Jung both confirmed that the security audit took place last October, and that actually the changes went into Zope-2.8.4, however, it wasn't brought to wider attention until 2.8.5. Please try to refrain from spreading further untruths in already murky waters. Alan From db-fedora at 3di.it Thu Feb 23 08:57:16 2006 From: db-fedora at 3di.it (Davide Bolcioni) Date: Thu, 23 Feb 2006 09:57:16 +0100 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <43FD0AC0.2090702@redhat.com> References: <43FD0AC0.2090702@redhat.com> Message-ID: <43FD78EC.4080104@3di.it> Mike A. Harris wrote: > Both ATI and Nvidia's proprietary video driver installation utilities > replace the Red Hat supplied libGL library with their own libGL. Could SELinux be used to prevent this and, more generally, disallow replacement of rpm-controlled files even by the root user ? Davide Bolcioni From arjan at fenrus.demon.nl Thu Feb 23 09:05:31 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 23 Feb 2006 10:05:31 +0100 Subject: Non-free Extras? In-Reply-To: References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> <43FC1F67.7080607@argo.co.il> <20060222120630.GD20029@devserv.devel.redhat.com> Message-ID: <1140685531.2972.18.camel@laptopd505.fenrus.org> > > With all the myriad hardware out there the open source community > cannot possibly develop drivers for everything. 5 years ago, I would have maybe believed this. Today, no. First, the open source community has gotten a lot bigger but second, and more important: Hardware is standardizing more and more (on the OS<->hardware interface level). Look at i810 audio for example. USB is a good other example. AHCI sata as well. These are not accidents! They are for cost saving reasons: if you're supported by a driver already shipping in windows XP, you as hardware vendor don't need to do a lot of work -> saves costs, and more, time to market -> profit. As a side effect of this, linux is increasingly better off. Sure there are exeptions, esp in the 3D space, but even there they do fully new architectures only every 18 months or so, just because it's so expensive to do entirely new drivers and then maintain them. (even when they are bundled as part of a "unified driver", most of these new architectures are de-facto new drivers, just merged into one binary file) From emeric.maschino at jouy.inra.fr Thu Feb 23 09:18:37 2006 From: emeric.maschino at jouy.inra.fr (Emeric Maschino) Date: Thu, 23 Feb 2006 10:18:37 +0100 Subject: GNOME desktop settings not saved Message-ID: <1140686317.7453.8.camel@localhost.localdomain> Hi, For several package updates now, my GNOME desktop settings aren't saved when I log out my session, most notably the desktop icon locations. There used to be a checkbox in the past asking for saving the changes at log out, but it disappeared in the latest package releases. I've noticed there's a similar option in the advanced preferences, but it has no effect on my system. Regarding the desktop icons, I'm always getting in this order: the Computer icon, an empty space, the Trash icon and the Home icon. I've seen on screenshots published on the web that there should be a Network Servers icon, but it's missing. The funny thing is that, if I completely erase the GNOME-related stuff in my home directory, the first time I'm logging in, the desktop icons are correctly organized: first, the Computer icon, then the Home icon and finally the Trash icon. Still no Network Servers icon however. But if I log out and log in again, the Home icon has been moved below the Trash icon, leaving an empty space between the Computer and Trash icons as described previously. Is there anybody out there experiencing the same annoyance? If needed, this is on an Itanium workstation with up-to-date Rawhide. I don't know if this is related, but when I log out my session, the countdown in the dialog box saying that my session will be automatically closed in 60 seconds isn't working (still displaying 60 seconds). Cheers, ?meric From emeric.maschino at jouy.inra.fr Thu Feb 23 09:23:19 2006 From: emeric.maschino at jouy.inra.fr (Emeric Maschino) Date: Thu, 23 Feb 2006 10:23:19 +0100 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: References: <43FD0AC0.2090702@redhat.com> Message-ID: <1140686599.7453.11.camel@localhost.localdomain> > Speaking of DRI, I have an ATI 200M. Using clean install of xorg driver, I > see this: > > (WW) RADEON(0): Enabling DRM support > > [...] > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is -1, (No such device or address) > [ repeat 255 times ...] > (II) RADEON(0): [drm] drmOpen failed > (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. > > I think I mentioned this here before, and IIRC someone else said they have > exactly the same result. Is this expected behavior? > > /sbin/lsmod > Module Size Used by > radeon 141665 0 > drm 117481 1 radeon > > drm is loaded, but there are no /dev/dri/ Same thing here with an ATI FireGL X1 (R300 chipset) on an Itanium workstation. From fedora at camperquake.de Thu Feb 23 09:39:10 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 23 Feb 2006 10:39:10 +0100 Subject: Hotplug: no more fstab entries In-Reply-To: <604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com> References: <20060222153244.002ea18c@dhcp05.addix.net> <43FC978E.6040006@feuerpokemon.de> <43FCB30D.2020509@unb.ca> <604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com> Message-ID: <20060223103910.2d9874ae@dhcp05.addix.net> Hi. On Wed, 22 Feb 2006 14:10:42 -0500, Jeff Spaleta wrote: > console is unreasonable in your estimation? Using the new gnome-mount > command on the cmdline in these situations to mimic what the gnome > desktop's automounter does is unreasonable? > > gnome-mount --help Hey, I need the complete Gnome library zoo just to mount a USB stick! This is progress for sure. From tmus at tmus.dk Thu Feb 23 10:03:26 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 23 Feb 2006 11:03:26 +0100 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <43FD78EC.4080104@3di.it> References: <43FD0AC0.2090702@redhat.com> <43FD78EC.4080104@3di.it> Message-ID: Davide Bolcioni wrote: > > Could SELinux be used to prevent this and, more generally, disallow > replacement of rpm-controlled files even by the root user ? > That would be incredibly annoying and is not where we want to go... It would complicate updates and installs and configuration and everything that is normal administration. People should just learn by their "mistakes" and replace whatever rpm their operations may have corrupted. I realize that some people need these rpms and thats why mharris kindly suggests that these people use the third party repos. Problem solved :o) /Thomas From che666 at gmail.com Thu Feb 23 10:24:07 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 23 Feb 2006 11:24:07 +0100 Subject: Non-free Extras? In-Reply-To: References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> <43FC1F67.7080607@argo.co.il> Message-ID: 2006/2/22, Benjy Grogan : > > > On 2/22/06, Avi Kivity wrote: > > Goede, J.W.R. de wrote: > > > > >Talking about solutions and not problems I propose: > > >-Fedora Extras (as is) > > >-Fedora Patent Encumbered (better name) aka > > > Debian non-US > > >-Fedora Non Commercial > > >-Fedora Non Free > > > > > > > > We would also need > > -Fedora for Non-Lawyers > > > > for ordinary users. How is one supposed to figure out where to look for > > things, and what all these repositories mean? This should be kept simple. > > > > Is there a way of including proprietary drivers with the Fedora Project? In > time, Nvidia, ATI et al will definitely have the best available linux > drivers for their hardware so it seems inevitable that proprietary drivers > will have to be included in Fedora. > > They're giving away their drivers for free anyways. > > Benji Those drivers taint the kernel and theres no source... also those drivers are not free as in freedom but rather free as in beer... How are fedora kernel maintainers/developers are going to support those modules if they dont even have the source? We (the zealots) want free drivers as part of the standard kernel. Tell nvidia and ati to get their drivers upstream, its as easy as that ;))). regards, Rudolf Kastl > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From ivg2 at cornell.edu Thu Feb 23 10:27:26 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 23 Feb 2006 05:27:26 -0500 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: References: <43FD0AC0.2090702@redhat.com> <43FD78EC.4080104@3di.it> Message-ID: <43FD8E0E.30602@cornell.edu> Davide Bolcioni wrote: >> >> Could SELinux be used to prevent this and, more generally, disallow >> replacement of rpm-controlled files even by the root user ? >> > > That would be incredibly annoying and is not where we want to go... It > would complicate updates and installs and configuration and everything > that is normal administration. I disagree, I think this would improve the security of the distribution. I would not recommend making such changes to targeted policy, but it seems potentially valuable to strict. Granting all powers to root is dangerous, we should be moving in the opposite direction, from coarse-grained security towards fine-grained security. I.E. applications ran as sysadm_t which don't need install (and relabeling) privileges shouldn't have them. I see no reason why my accidental execution of a hostile script as sysadm_t should have the powers to take over my computer. I think strict policy has already been changed to run in an underprivileged role by default (staff_r) for root logins, so I'm not sure if more needs to be done... From che666 at gmail.com Thu Feb 23 10:34:24 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 23 Feb 2006 11:34:24 +0100 Subject: Non-free Extras? In-Reply-To: <1140685531.2972.18.camel@laptopd505.fenrus.org> References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> <43FC1F67.7080607@argo.co.il> <20060222120630.GD20029@devserv.devel.redhat.com> <1140685531.2972.18.camel@laptopd505.fenrus.org> Message-ID: 2006/2/23, Arjan van de Ven : > > > > > With all the myriad hardware out there the open source community > > cannot possibly develop drivers for everything. > > 5 years ago, I would have maybe believed this. > Today, no. > First, the open source community has gotten a lot bigger > but second, and more important: > Hardware is standardizing more and more (on the OS<->hardware interface > level). Look at i810 audio for example. USB is a good other example. > AHCI sata as well. > > These are not accidents! They are for cost saving reasons: if you're > supported by a driver already shipping in windows XP, you as hardware > vendor don't need to do a lot of work -> saves costs, and more, time to > market -> profit. > > As a side effect of this, linux is increasingly better off. > > Sure there are exeptions, esp in the 3D space, but even there they do > fully new architectures only every 18 months or so, just because it's so > expensive to do entirely new drivers and then maintain them. > (even when they are bundled as part of a "unified driver", most of these > new architectures are de-facto new drivers, just merged into one binary > file) > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > >From personal experience i do agree. simple example: socket 939 nforce 4x board fc4 vs winxp pro sp2 integrated: FC4: everything working out of the box no additional drivers needed besides raid didnt work in the installer. (known problem) Rawhide: Raid controller works out of the box aswell WinXP pro SP2: Onboard nic not working at all and downloading of driver not possible since no working NIC. regards, Rudolf Kastl From ivg2 at cornell.edu Thu Feb 23 10:54:35 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 23 Feb 2006 05:54:35 -0500 Subject: Non-free Extras? In-Reply-To: References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> <43FC1F67.7080607@argo.co.il> <20060222120630.GD20029@devserv.devel.redhat.com> <1140685531.2972.18.camel@laptopd505.fenrus.org> Message-ID: <43FD946B.5030108@cornell.edu> > >From personal experience i do agree. simple example: > > socket 939 nforce 4x board fc4 vs winxp pro sp2 integrated: > > FC4: everything working out of the box no additional drivers needed > besides raid didnt work in the installer. (known problem) > Rawhide: Raid controller works out of the box aswell > WinXP pro SP2: Onboard nic not working at all and downloading of > driver not possible since no working NIC. Can we please stop posting meaningless examples? Six years ago, when I started playing around with Linux I couldn't get my Lucent winmodem to work, and Red Hat would not support it (which was infuriating for a paying customer). Today, my wireless card does not run out of the box. By the argument you present above, I should conclude that Linux has made no progress in six years. Right now we're at 50% supported hardware (yours works, and mine doesn't). 05:08.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC ( rev 01) Installation of the Windows driver clearly not possible, so I'm in no better position than you on WinXP. From che666 at gmail.com Thu Feb 23 11:04:00 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 23 Feb 2006 12:04:00 +0100 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <43FD8E0E.30602@cornell.edu> References: <43FD0AC0.2090702@redhat.com> <43FD78EC.4080104@3di.it> <43FD8E0E.30602@cornell.edu> Message-ID: 2006/2/23, Ivan Gyurdiev : > Davide Bolcioni wrote: > >> > >> Could SELinux be used to prevent this and, more generally, disallow > >> replacement of rpm-controlled files even by the root user ? > >> > > > > That would be incredibly annoying and is not where we want to go... It > > would complicate updates and installs and configuration and everything > > that is normal administration. > I disagree, I think this would improve the security of the distribution. > I would not recommend making such changes to targeted policy, but it > seems potentially valuable to strict. > > Granting all powers to root is dangerous, we should be moving in the > opposite direction, from coarse-grained security towards fine-grained > security. I.E. applications ran as sysadm_t which don't need install > (and relabeling) privileges shouldn't have them. agreed. > > I see no reason why my accidental execution of a hostile script as > sysadm_t should have the powers to take over my computer. > I think strict policy has already been changed to run in an > underprivileged role by default (staff_r) for root logins, so I'm not > sure if more needs to be done... agreed regards, Rudolf Kastl my personal conclusion: While there should be mechanisms to turn off the "rpm file protection" it would by default be nice since users stop wrecking their systems and reporting bogus bugs. regards, Rudolf Kastl > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From che666 at gmail.com Thu Feb 23 11:05:39 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 23 Feb 2006 12:05:39 +0100 Subject: Non-free Extras? In-Reply-To: <43FD946B.5030108@cornell.edu> References: <43FBA1CD.4020908@gmail.com> <43FC1F67.7080607@argo.co.il> <20060222120630.GD20029@devserv.devel.redhat.com> <1140685531.2972.18.camel@laptopd505.fenrus.org> <43FD946B.5030108@cornell.edu> Message-ID: 2006/2/23, Ivan Gyurdiev : > > > >From personal experience i do agree. simple example: > > > > socket 939 nforce 4x board fc4 vs winxp pro sp2 integrated: > > > > FC4: everything working out of the box no additional drivers needed > > besides raid didnt work in the installer. (known problem) > > Rawhide: Raid controller works out of the box aswell > > WinXP pro SP2: Onboard nic not working at all and downloading of > > driver not possible since no working NIC. > Can we please stop posting meaningless examples? > > Six years ago, when I started playing around with Linux I couldn't get > my Lucent winmodem to work, and Red Hat would not support it (which was > infuriating for a paying customer). Today, my wireless card does not run > out of the box. By the argument you present above, I should conclude > that Linux has made no progress in six years. Right now we're at 50% > supported hardware (yours works, and mine doesn't). > > 05:08.0 Ethernet controller: Atheros Communications, Inc. AR5212 > 802.11abg NIC ( rev 01) > Installation of the Windows driver clearly not possible, so I'm in no > better position than you on WinXP. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > i had my lucent windmodem working with rh 7.3 just fine. so to me this example is rather meaningless. regards, Rudolf Kastl From che666 at gmail.com Thu Feb 23 11:18:09 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 23 Feb 2006 12:18:09 +0100 Subject: Non-free Extras? In-Reply-To: <43FD946B.5030108@cornell.edu> References: <43FBA1CD.4020908@gmail.com> <43FC1F67.7080607@argo.co.il> <20060222120630.GD20029@devserv.devel.redhat.com> <1140685531.2972.18.camel@laptopd505.fenrus.org> <43FD946B.5030108@cornell.edu> Message-ID: 2006/2/23, Ivan Gyurdiev : > > > >From personal experience i do agree. simple example: > > > > socket 939 nforce 4x board fc4 vs winxp pro sp2 integrated: > > > > FC4: everything working out of the box no additional drivers needed > > besides raid didnt work in the installer. (known problem) > > Rawhide: Raid controller works out of the box aswell > > WinXP pro SP2: Onboard nic not working at all and downloading of > > driver not possible since no working NIC. > Can we please stop posting meaningless examples? > > Six years ago, when I started playing around with Linux I couldn't get > my Lucent winmodem to work, and Red Hat would not support it (which was > infuriating for a paying customer). There was always a hacked windows driver that worked just fine... no source for it though so how would an open source company support it? Its quite a different deal with hardware that doesent have specs available. For someone migrating to linux it can be bad luck... for a long time user of linux with the intention to have stuff working i see 2 options: 1. reengineer it and write a driver 2. get the vendor to release specs and someone to write a driver 3. or buy hardware that works again my centrino laptop has no wireless problems and i dont need the ndiswrapper crap either ;) regards, Rudolf Kastl p.s. i see no point here either to get more indepth of the topic. Today, my wireless card does not run > out of the box. By the argument you present above, I should conclude > that Linux has made no progress in six years. Right now we're at 50% > supported hardware (yours works, and mine doesn't). > > 05:08.0 Ethernet controller: Atheros Communications, Inc. AR5212 > 802.11abg NIC ( rev 01) > Installation of the Windows driver clearly not possible, so I'm in no > better position than you on WinXP. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From gazzerh at gmail.com Thu Feb 23 11:18:29 2006 From: gazzerh at gmail.com (Garry Harthill) Date: Thu, 23 Feb 2006 11:18:29 +0000 Subject: GNOME desktop settings not saved In-Reply-To: <1140686317.7453.8.camel@localhost.localdomain> References: <1140686317.7453.8.camel@localhost.localdomain> Message-ID: <1fcc9e320602230318w72fa063bi@mail.gmail.com> On 23/02/06, Emeric Maschino wrote: > Hi, > > For several package updates now, my GNOME desktop settings aren't saved > when I log out my session, most notably the desktop icon locations. > There used to be a checkbox in the past asking for saving the changes at > log out, but it disappeared in the latest package releases. I've noticed > there's a similar option in the advanced preferences, but it has no > effect on my system. Regarding the desktop icons, I'm always getting in > this order: the Computer icon, an empty space, the Trash icon and the > Home icon. I've seen on screenshots published on the web that there > should be a Network Servers icon, but it's missing. The funny thing is > that, if I completely erase the GNOME-related stuff in my home > directory, the first time I'm logging in, the desktop icons are > correctly organized: first, the Computer icon, then the Home icon and > finally the Trash icon. Still no Network Servers icon however. But if I > log out and log in again, the Home icon has been moved below the Trash > icon, leaving an empty space between the Computer and Trash icons as > described previously. > > Is there anybody out there experiencing the same annoyance? If needed, > this is on an Itanium workstation with up-to-date Rawhide. > > I don't know if this is related, but when I log out my session, the > countdown in the dialog box saying that my session will be automatically > closed in 60 seconds isn't working (still displaying 60 seconds). > > Cheers, > > ?meric > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I am getting the same problem as you. I have to move the home icon up to the blank space everytime i restart X. I'm not sure how to save the settings manually. I remember the save settings dialog when you restarted in the past. Why has this been removed? From db-fedora at 3di.it Thu Feb 23 11:24:13 2006 From: db-fedora at 3di.it (Davide Bolcioni) Date: Thu, 23 Feb 2006 12:24:13 +0100 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: References: <43FD0AC0.2090702@redhat.com> <43FD78EC.4080104@3di.it> <43FD8E0E.30602@cornell.edu> Message-ID: <43FD9B5D.7050200@3di.it> Rudolf Kastl wrote: > my personal conclusion: > > While there should be mechanisms to turn off the "rpm file protection" > it would by default be nice since users stop wrecking their systems > and reporting bogus bugs. A boolean named "invalidate_rhel_support_contract", false by default, should fit the bill. This protection would not apply to configuration or data files, of course, only to files which have no need to be writable for ordinary execution. Regards, Davide Bolcioni -- Paranoia is a survival asset. From arjan at fenrus.demon.nl Thu Feb 23 11:24:40 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 23 Feb 2006 12:24:40 +0100 Subject: Non-free Extras? In-Reply-To: <43FD946B.5030108@cornell.edu> References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> <43FC1F67.7080607@argo.co.il> <20060222120630.GD20029@devserv.devel.redhat.com> <1140685531.2972.18.camel@laptopd505.fenrus.org> <43FD946B.5030108@cornell.edu> Message-ID: <1140693880.4672.40.camel@laptopd505.fenrus.org> > > Six years ago, when I started playing around with Linux I couldn't get > my Lucent winmodem to work, and Red Hat would not support it (which was > infuriating for a paying customer). the good news is that nowadays there is a proper solution for these > Today, my wireless card does not run > out of the box. By the argument you present above, I should conclude > that Linux has made no progress in six years. Right now we're at 50% > supported hardware (yours works, and mine doesn't). > > 05:08.0 Ethernet controller: Atheros Communications, Inc. AR5212 > 802.11abg NIC ( rev 01) but these have open source drivers (I'm not talking about the madwifi proprietary ones, but about the reverse engineered ones). Sure they're not in fedora (yet), but the work on wireless recently picked up bigtime so I have good hopes for Fedora Core 6 having a lot better wireless hw support. From pknirsch at redhat.com Thu Feb 23 12:18:17 2006 From: pknirsch at redhat.com (Phil Knirsch) Date: Thu, 23 Feb 2006 13:18:17 +0100 Subject: Results for install and remove tests for FC-Devel In-Reply-To: <20060222171227.GE5568@devserv.devel.redhat.com> References: <43FC3ECA.9020100@redhat.com> <20060222171227.GE5568@devserv.devel.redhat.com> Message-ID: <43FDA809.8060708@redhat.com> Bill Nottingham wrote: > Phil Knirsch (pknirsch at redhat.com) said: >> As i've written last Friday, i have been running a complete install and >> removal test for all packages of the Friday snapshot of FC-Devel. > > Is it possible to get this filtered into bugzilla without a herculean > amount of manual effort? > > Bill > Sure, will do it today, Bill. 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 pknirsch at redhat.com Thu Feb 23 12:21:29 2006 From: pknirsch at redhat.com (Phil Knirsch) Date: Thu, 23 Feb 2006 13:21:29 +0100 Subject: Results for install and remove tests for FC-Devel In-Reply-To: References: <43FC3ECA.9020100@redhat.com> <20060222140044.GA2959@free.fr> <43FC7E02.1000705@volny.cz> <43FC829C.2060502@redhat.com> Message-ID: <43FDA8C9.7080808@redhat.com> Rex Dieter wrote: > Phil Knirsch wrote: >> there are actually quite a few packages that can break if >> coreutils isn't installed prior to them, so this is really a missing >> PreReq dependency. > > Or more precisely, they're missing at least one of > Requires(post): coreutils > Requiers(pre): coreutils > > PreReq implies also that coreutils is required after-install/at-runtime, > which may or may not be true. > Yes, exactly. PreReq itself is the socalled legacy prerequires, which basically covers everything and oversimplified states that the mentioned requirement needs to be met before anything concerning the package can be done. 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 pknirsch at redhat.com Thu Feb 23 12:44:11 2006 From: pknirsch at redhat.com (Phil Knirsch) Date: Thu, 23 Feb 2006 13:44:11 +0100 Subject: Results for install and remove tests for FC-Devel In-Reply-To: <20060222155424.GB2959@free.fr> References: <43FC3ECA.9020100@redhat.com> <20060222140044.GA2959@free.fr> <43FC7E02.1000705@volny.cz> <43FC829C.2060502@redhat.com> <20060222155424.GB2959@free.fr> Message-ID: <43FDAE1B.1020603@redhat.com> Patrice Dumas wrote: >> Yeah, i forgot to mention, this whole test is mainly for completeness. >> Quite a few packages have coreutils as a requirement in Fedora Core, and >> for packages that have a real PreReq this actually makes sense and is >> certainly needed as rpm otherwise could always just put coreutils at >> some later point in the install order and suddenly tons of pre or post >> install scripts would break. And thats basically what this test >> revealed, that there are actually quite a few packages that can break if >> coreutils isn't installed prior to them, so this is really a missing >> PreReq dependency. > > Thanks for the explanation... Indeed it isn't a live system but a > filesystem being populated at the same time scripts are run, so having > coreutils required is indeed important. Maybe, when the filesystem is > depopulated coreutils cannot be removed anyway but who knows, it is indeed > still a good thing to have everything right. > > I don't know if it is easy/possible/interesting, but if it is, could it be > possible to do similar things for extras without too much work? Or maybe > it is too early as extras are not handled by anaconda anyway? > Yes, of course, the test can be run on FC-Extras as well without much work as everything except the reporting is automated. I wanted to rerun the test anyway sometime soon on a different (and much faster) machine. The test just takes very long to run. The one i did now took about 70 hours altogether on a "standard" desktop machine. But if you think about it, this was for over 2200 packages. This test therefore basically did 2200 complete installs and remvoals which boils down to about 2 minutes per package for the whole install/remove operation, and that's really fast. 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 david at fubar.dk Thu Feb 23 12:47:34 2006 From: david at fubar.dk (David Zeuthen) Date: Thu, 23 Feb 2006 07:47:34 -0500 Subject: Hotplug: no more fstab entries In-Reply-To: <20060223103910.2d9874ae@dhcp05.addix.net> References: <20060222153244.002ea18c@dhcp05.addix.net> <43FC978E.6040006@feuerpokemon.de> <43FCB30D.2020509@unb.ca> <604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com> <20060223103910.2d9874ae@dhcp05.addix.net> Message-ID: <1140698854.3633.1.camel@daxter.boston.redhat.com> On Thu, 2006-02-23 at 10:39 +0100, Ralf Ertzinger wrote: > Hey, I need the complete Gnome library zoo just to mount a USB stick! > This is progress for sure. Don't be silly. You can still use /etc/fstab and/or mount(1). Even with the new /disk/disk/by-label etc. symlinks you can construct a persistent entry in /etc/fstab. David From alan at redhat.com Thu Feb 23 13:08:42 2006 From: alan at redhat.com (Alan Cox) Date: Thu, 23 Feb 2006 08:08:42 -0500 Subject: Multiple concurrent versions of Python In-Reply-To: <17264.192.54.193.25.1140626141.squirrel@rousalka.dyndns.org> References: <48385.192.54.193.25.1140605725.squirrel@rousalka.dyndns.org> <10428.192.54.193.25.1140612258.squirrel@rousalka.dyndns.org> <17264.192.54.193.25.1140626141.squirrel@rousalka.dyndns.org> Message-ID: <20060223130842.GA977@devserv.devel.redhat.com> On Wed, Feb 22, 2006 at 05:35:41PM +0100, Nicolas Mailhot wrote: > > They just ask people to build their own python 2.3.5 in /usr/local, and > > then install Zope with it. > > Like I wrote, this is as bad as closed software tools ;( I guess that Thats not really the case. You can help port Zope to a new python if you want it. From fedora at camperquake.de Thu Feb 23 13:19:25 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 23 Feb 2006 14:19:25 +0100 Subject: Hotplug: no more fstab entries In-Reply-To: <1140698854.3633.1.camel@daxter.boston.redhat.com> References: <20060222153244.002ea18c@dhcp05.addix.net> <43FC978E.6040006@feuerpokemon.de> <43FCB30D.2020509@unb.ca> <604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com> <20060223103910.2d9874ae@dhcp05.addix.net> <1140698854.3633.1.camel@daxter.boston.redhat.com> Message-ID: <20060223141925.5a085d71@dhcp05.addix.net> Hi. On Thu, 23 Feb 2006 07:47:34 -0500, David Zeuthen wrote: > Don't be silly. You can still use /etc/fstab and/or mount(1). Even > with the new /disk/disk/by-label etc. symlinks you can construct a > persistent entry in /etc/fstab. Nonetheless, what was wrong with the old behaviour (dropping a directory in /media for each plugged in device)? I do not even particulary care about the entries in /etc/fstab, as long as "mount /media/usbdisk" does what it is supposed to do. Can I restore the old behaviour somehow? From david at fubar.dk Thu Feb 23 13:31:47 2006 From: david at fubar.dk (David Zeuthen) Date: Thu, 23 Feb 2006 08:31:47 -0500 Subject: Hotplug: no more fstab entries In-Reply-To: <20060223141925.5a085d71@dhcp05.addix.net> References: <20060222153244.002ea18c@dhcp05.addix.net> <43FC978E.6040006@feuerpokemon.de> <43FCB30D.2020509@unb.ca> <604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com> <20060223103910.2d9874ae@dhcp05.addix.net> <1140698854.3633.1.camel@daxter.boston.redhat.com> <20060223141925.5a085d71@dhcp05.addix.net> Message-ID: <1140701508.3633.9.camel@daxter.boston.redhat.com> On Thu, 2006-02-23 at 14:19 +0100, Ralf Ertzinger wrote: > Hi. > > On Thu, 23 Feb 2006 07:47:34 -0500, David Zeuthen wrote: > > > Don't be silly. You can still use /etc/fstab and/or mount(1). Even > > with the new /disk/disk/by-label etc. symlinks you can construct a > > persistent entry in /etc/fstab. > > Nonetheless, what was wrong with the old behaviour (dropping a directory > in /media for each plugged in device)? I do not even particulary care about > the entries in /etc/fstab, as long as "mount /media/usbdisk" does what it > is supposed to do. The thing is... we don't know a priori what mount point (and mount options) is to be used. With gnome-mount, this decision now comes from the desktop session. Right now the logic is hard wired into the gnome-mount sources itself but we're working on fixing this to read it from gconf; see http://freedesktop.org/~david/gnome-mount-properties-0.01.png for some work in progress. > Can I restore the old behaviour somehow? Not really, no. But nothing prevents you from write an fstab-sync like program yourself and submitting it to Fedora Extras. David From dragoran at feuerpokemon.de Thu Feb 23 13:43:38 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 23 Feb 2006 14:43:38 +0100 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: References: <43FD0AC0.2090702@redhat.com> <43FD78EC.4080104@3di.it> Message-ID: <43FDBC0A.7040208@feuerpokemon.de> Thomas M Steenholdt wrote: > Davide Bolcioni wrote: > >> >> Could SELinux be used to prevent this and, more generally, disallow >> replacement of rpm-controlled files even by the root user ? >> > > That would be incredibly annoying and is not where we want to go... It > would complicate updates and installs and configuration and everything > that is normal administration. > > People should just learn by their "mistakes" and replace whatever rpm > their operations may have corrupted. > > I realize that some people need these rpms and thats why mharris > kindly suggests that these people use the third party repos. > > Problem solved :o) > > /Thomas > > won't help ... people will ask on the nvidia forums an get a reply "do setenforce 0 before installing the driver and setenforce 1 after it finished" From veillard at redhat.com Thu Feb 23 13:54:46 2006 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 23 Feb 2006 08:54:46 -0500 Subject: Xen issues - Was Xen network performance problem during kickstart. In-Reply-To: <1140663339.2870.6.camel@dragon.sys.intra> References: <1139987549.21111.68.camel@dragon.sys.intra> <1140052865.2302.64.camel@host-81-191-138-132.bluecom.no> <1140060379.21111.145.camel@dragon.sys.intra> <1140078535.4651.84.camel@dragon.sys.intra> <1140157902.3229.32.camel@dragon.sys.intra> <1140442863.3357.4.camel@orbit.scot.redhat.com> <1140451864.2384.81.camel@dragon.sys.intra> <1140508134.2384.126.camel@dragon.sys.intra> <20060221103132.GA9506@redhat.com> <1140663339.2870.6.camel@dragon.sys.intra> Message-ID: <20060223135446.GZ9506@redhat.com> On Thu, Feb 23, 2006 at 11:55:39AM +0900, Naoki wrote: > > New bug :) Anybody else see this. I tried the same type of install as > before expect this time thought I'd give it 512MB RAM instead of 256M. > > ------------[ cut here ]------------ > kernel BUG at include/asm/xor.h:633! > invalid opcode: 0000 [#1] I think I have seen this reported a couple of times already, check with latest versions. Daniel -- Daniel Veillard | Red Hat 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 che666 at gmail.com Thu Feb 23 13:55:15 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 23 Feb 2006 14:55:15 +0100 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <43FDBC0A.7040208@feuerpokemon.de> References: <43FD0AC0.2090702@redhat.com> <43FD78EC.4080104@3di.it> <43FDBC0A.7040208@feuerpokemon.de> Message-ID: 2006/2/23, dragoran : > Thomas M Steenholdt wrote: > > > Davide Bolcioni wrote: > > > >> > >> Could SELinux be used to prevent this and, more generally, disallow > >> replacement of rpm-controlled files even by the root user ? > >> > > > > That would be incredibly annoying and is not where we want to go... It > > would complicate updates and installs and configuration and everything > > that is normal administration. > > > > People should just learn by their "mistakes" and replace whatever rpm > > their operations may have corrupted. > > > > I realize that some people need these rpms and thats why mharris > > kindly suggests that these people use the third party repos. > > > > Problem solved :o) > > > > /Thomas > > > > > won't help ... > people will ask on the nvidia forums an get a reply "do setenforce 0 > before installing the driver and setenforce 1 after it finished" thats definitely a worst case scenario ;) regards, rudolf kastl > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From dedourek at unb.ca Thu Feb 23 14:02:55 2006 From: dedourek at unb.ca (John DeDourek) Date: Thu, 23 Feb 2006 10:02:55 -0400 Subject: Hotplug: no more fstab entries In-Reply-To: <1140701508.3633.9.camel@daxter.boston.redhat.com> References: <20060222153244.002ea18c@dhcp05.addix.net> <43FC978E.6040006@feuerpokemon.de> <43FCB30D.2020509@unb.ca> <604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com> <20060223103910.2d9874ae@dhcp05.addix.net> <1140698854.3633.1.camel@daxter.boston.redhat.com> <20060223141925.5a085d71@dhcp05.addix.net> <1140701508.3633.9.camel@daxter.boston.redhat.com> Message-ID: <43FDC08F.3040805@unb.ca> David Zeuthen wrote: >On Thu, 2006-02-23 at 14:19 +0100, Ralf Ertzinger wrote: > > >>Hi. >> >>On Thu, 23 Feb 2006 07:47:34 -0500, David Zeuthen wrote: >> >> >> >>>Don't be silly. You can still use /etc/fstab and/or mount(1). Even >>>with the new /disk/disk/by-label etc. symlinks you can construct a >>>persistent entry in /etc/fstab. >>> >>> >>Nonetheless, what was wrong with the old behaviour (dropping a directory >>in /media for each plugged in device)? I do not even particulary care about >>the entries in /etc/fstab, as long as "mount /media/usbdisk" does what it >>is supposed to do. >> >> > >The thing is... we don't know a priori what mount point (and mount >options) is to be used. With gnome-mount, this decision now comes from >the desktop session. Right now the logic is hard wired into the >gnome-mount sources itself but we're working on fixing this to read it >from gconf; see > > http://freedesktop.org/~david/gnome-mount-properties-0.01.png > >for some work in progress. > > > >>Can I restore the old behaviour somehow? >> >> > >Not really, no. But nothing prevents you from write an fstab-sync like >program yourself and submitting it to Fedora Extras. > > David > > > > Unfortunately, the arguments are piling on for re-evaluating our distro choice here. Another thread in this group suggested that the poster get one of the handy linux reference books to solve some mounting problems. I bet they say "mount" and "fstab". (Has anyone checked wheter posix mandates "mount" for mounting?) From ivg2 at cornell.edu Thu Feb 23 14:04:05 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 23 Feb 2006 09:04:05 -0500 Subject: Where did all my memory go? Message-ID: <43FDC0D5.1050901@cornell.edu> So I decided to hunt for bugs (which there's a lot of...) by running rpm -Va to see which packages conflict, and what other damage is there in the database. Then the computer got slower, and slower, and slower.... And several hours later it got done (I have a lot of packages, I don't know how fast it should be) Now I see: total used free shared buffers cached Mem: 1025512 1016696 8816 0 1668 39980 -/+ buffers/cache: 975048 50464 Swap: 524152 261924 262228 There were prelink/rpmv zombies which I killed. Firefox and thunderbir were eating a lot of memory as usual, but I killed those too. The result above is afterwards, with not much running other than a standard gnome desktop. The top process by resident memory is eating 40MB or so. Kernel (1959 + madwifi + Nvidia + Steve' Grubb's lspp things): 2.6.15-1.1959.2.1_FC5.lspp.9 slabtop: 12535365 12535330 99% 0.05K 187095 67 748380K size-32 869924 869896 99% 0.09K 19771 44 79084K size-64 93632 93622 99% 0.05K 1216 77 4864K avtab_node 14500 4918 33% 0.15K 580 25 2320K size-128 11210 10221 91% 0.20K 590 19 2360K vm_area_struct What's using up all the memory? From mclasen at redhat.com Thu Feb 23 14:07:41 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 23 Feb 2006 09:07:41 -0500 Subject: Hotplug: no more fstab entries In-Reply-To: <20060223103910.2d9874ae@dhcp05.addix.net> References: <20060222153244.002ea18c@dhcp05.addix.net> <43FC978E.6040006@feuerpokemon.de> <43FCB30D.2020509@unb.ca> <604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com> <20060223103910.2d9874ae@dhcp05.addix.net> Message-ID: <1140703661.23024.46.camel@golem.boston.redhat.com> On Thu, 2006-02-23 at 10:39 +0100, Ralf Ertzinger wrote: > Hi. > > On Wed, 22 Feb 2006 14:10:42 -0500, Jeff Spaleta wrote: > > > console is unreasonable in your estimation? Using the new gnome-mount > > command on the cmdline in these situations to mimic what the gnome > > desktop's automounter does is unreasonable? > > > > gnome-mount --help > > Hey, I need the complete Gnome library zoo just to mount a USB stick! > This is progress for sure. Last time I looked, gnome-mount was only using GTK+. From jspaleta at gmail.com Thu Feb 23 14:08:09 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 23 Feb 2006 09:08:09 -0500 Subject: Hotplug: no more fstab entries In-Reply-To: <1140701508.3633.9.camel@daxter.boston.redhat.com> References: <20060222153244.002ea18c@dhcp05.addix.net> <43FC978E.6040006@feuerpokemon.de> <43FCB30D.2020509@unb.ca> <604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com> <20060223103910.2d9874ae@dhcp05.addix.net> <1140698854.3633.1.camel@daxter.boston.redhat.com> <20060223141925.5a085d71@dhcp05.addix.net> <1140701508.3633.9.camel@daxter.boston.redhat.com> Message-ID: <604aa7910602230608r34dfc1a1r17abe661f0b0dc9b@mail.gmail.com> On 2/23/06, David Zeuthen wrote: > http://freedesktop.org/~david/gnome-mount-properties-0.01.png > > for some work in progress. Is there be a cmdline oriented tool planned to do what the gui gnome-mount-properties does to balance the functionality of gnome-mount on the cmdline? Or will we be asked to use gconftool to edit these keys from the cmdline? -jef From mailinglists at erwinrol.com Thu Feb 23 14:09:44 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Thu, 23 Feb 2006 15:09:44 +0100 Subject: Where did all my memory go? In-Reply-To: <43FDC0D5.1050901@cornell.edu> References: <43FDC0D5.1050901@cornell.edu> Message-ID: <1140703784.4957.24.camel@xpc.home.erwinrol.com> On Thu, 2006-02-23 at 09:04 -0500, Ivan Gyurdiev wrote: > Kernel (1959 + madwifi + Nvidia + Steve' Grubb's lspp things): > 2.6.15-1.1959.2.1_FC5.lspp.9 And how is anybody here going to be able to debug or even only guess what is wrong when using a kernel like that ? - Erwin From ivg2 at cornell.edu Thu Feb 23 14:16:31 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 23 Feb 2006 09:16:31 -0500 Subject: Where did all my memory go? In-Reply-To: <1140703784.4957.24.camel@xpc.home.erwinrol.com> References: <43FDC0D5.1050901@cornell.edu> <1140703784.4957.24.camel@xpc.home.erwinrol.com> Message-ID: <43FDC3BF.8090101@cornell.edu> > And how is anybody here going to be able to debug or even only guess > what is wrong when using a kernel like that ? > Well, I would assume, by having a better idea about how memory allocations work, and how they can be tracked, people could hint me as to how to figure out what's eating all the memory (since the top command isn't helping). Maybe three's a command I don't know about, or /proc statistics that could explain what's happening. If I knew how to debug the problem I wouldn't be asking the question, would I? I guess I should cc Steve Grubb on this, since the kernel does include lspp patches. From mitr at volny.cz Thu Feb 23 14:30:43 2006 From: mitr at volny.cz (Miloslav Trmac) Date: Thu, 23 Feb 2006 15:30:43 +0100 Subject: Hotplug: no more fstab entries In-Reply-To: <43FDC08F.3040805@unb.ca> References: <20060222153244.002ea18c@dhcp05.addix.net> <43FC978E.6040006@feuerpokemon.de> <43FCB30D.2020509@unb.ca> <604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com> <20060223103910.2d9874ae@dhcp05.addix.net> <1140698854.3633.1.camel@daxter.boston.redhat.com> <20060223141925.5a085d71@dhcp05.addix.net> <1140701508.3633.9.camel@daxter.boston.redhat.com> <43FDC08F.3040805@unb.ca> Message-ID: <43FDC713.7080401@volny.cz> John DeDourek napsal(a): > (Has anyone checked wheter posix mandates "mount" for mounting?) You can :) (man 1p mount) on any recent (IIRC FC4 or newer) Fedora system. Mirek From dwmw2 at infradead.org Thu Feb 23 14:34:57 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 23 Feb 2006 14:34:57 +0000 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <43FD0AC0.2090702@redhat.com> References: <43FD0AC0.2090702@redhat.com> Message-ID: <1140705297.3803.158.camel@pmac.infradead.org> On Wed, 2006-02-22 at 20:07 -0500, Mike A. Harris wrote: > Both ATI and Nvidia, and perhaps even other 3rd party drivers out there > come in some form of tarball or equivalent form from the particular > vendor. The Intel driver is worse than that, in some ways. In that case you don't even need to seek out and install separate software; a clean Fedora installation out of the box will run binary-only code supplied by your board manufacturer, without really giving you much clue that it's doing so. I recently purchased a board with Intel i915 graphics, because I was led to believe that it had a fully open source driver -- and now I've found that all the mode setup is in binary-only code. So I can't make it do the PAL output modes for which I purchased it. -- dwmw2 From galibert at pobox.com Thu Feb 23 14:35:55 2006 From: galibert at pobox.com (Olivier Galibert) Date: Thu, 23 Feb 2006 15:35:55 +0100 Subject: Where did all my memory go? In-Reply-To: <43FDC0D5.1050901@cornell.edu> References: <43FDC0D5.1050901@cornell.edu> Message-ID: <20060223143555.GA36205@dspnet.fr.eu.org> On Thu, Feb 23, 2006 at 09:04:05AM -0500, Ivan Gyurdiev wrote: [...rpm -Va...] > What's using up all the memory? File caching, obviously. Current VM is not that good at handling streaming a bunch of files through an application. Well, it agressively caches the file for the application itself, too bad it doesn't care about them anymore after one load, and meanwhile swaps out whatever is on the computer too. OG. From alan at redhat.com Thu Feb 23 14:39:34 2006 From: alan at redhat.com (Alan Cox) Date: Thu, 23 Feb 2006 09:39:34 -0500 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <1140705297.3803.158.camel@pmac.infradead.org> References: <43FD0AC0.2090702@redhat.com> <1140705297.3803.158.camel@pmac.infradead.org> Message-ID: <20060223143934.GA4138@devserv.devel.redhat.com> On Thu, Feb 23, 2006 at 02:34:57PM +0000, David Woodhouse wrote: > Fedora installation out of the box will run binary-only code supplied by > your board manufacturer, without really giving you much clue that it's > doing so. Correct. Each intel board has board specific analogue circuitry and interfaces which are driven via a BIOS interface. X would need a driver for each motherboard (and potentially each board rev) to do anything else Alan From jspaleta at gmail.com Thu Feb 23 14:34:00 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 23 Feb 2006 09:34:00 -0500 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: References: <43FD0AC0.2090702@redhat.com> <43FD78EC.4080104@3di.it> <43FDBC0A.7040208@feuerpokemon.de> Message-ID: <604aa7910602230634l5751103v11690aa4e241fcab@mail.gmail.com> On 2/23/06, Rudolf Kastl wrote: > thats definitely a worst case scenario ;) And sadly the most likely one, until there are some end-user oriented notifications from the system which explain what is going on and why, when an selinux related denial happens. Having to keep a running tail of /var/log/messages open and learning how to decipher the avc messages while using vendor installers is a hurdle an order of magnitude too large for normal home users who don't understand the underlying issues. And sadly, reaching out to other users tends to get you blanket "turn off" selinux answers. There is a steep learning curve associated with selinux denials, and unless the fedora system makes an attempt to point users to granular tools as the denials occur the re-education effort is going to be hamstrung. -jef From caolanm at redhat.com Thu Feb 23 14:41:23 2006 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 23 Feb 2006 14:41:23 +0000 Subject: preview native x86_64 openoffice.org rpms Message-ID: <1140705683.11992.3.camel@localhost.localdomain> rpms of a native x86_64 version of openoffice.org as created by the OOo build process (680_m157/i.e. in fedora parlance equivalent to 2.0.3-0.157) at http://people.redhat.com/caolanm/x86_64/ "binfilter", i.e. support for legacy binary StarOffice support is disabled, but everything else is in there. Seems to work ok :-), though there might be nasties in there. C. From arjan at fenrus.demon.nl Thu Feb 23 14:42:16 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 23 Feb 2006 15:42:16 +0100 Subject: Where did all my memory go? In-Reply-To: <43FDC3BF.8090101@cornell.edu> References: <43FDC0D5.1050901@cornell.edu> <1140703784.4957.24.camel@xpc.home.erwinrol.com> <43FDC3BF.8090101@cornell.edu> Message-ID: <1140705737.4672.59.camel@laptopd505.fenrus.org> On Thu, 2006-02-23 at 09:16 -0500, Ivan Gyurdiev wrote: > > And how is anybody here going to be able to debug or even only guess > > what is wrong when using a kernel like that ? > > > Well, I would assume, by having a better idea about how memory > allocations work, and how they can be tracked, people could hint me as > to how to figure out what's eating all the memory (since the top command > isn't helping). Maybe three's a command I don't know about, or /proc > statistics that could explain what's happening. If I knew how to debug > the problem I wouldn't be asking the question, would I? > > I guess I should cc Steve Grubb on this, since the kernel does include > lspp patches. also ask nvidia and madwifi for help first I suppose ;) From j.w.r.degoede at hhs.nl Thu Feb 23 15:10:20 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 23 Feb 2006 16:10:20 +0100 Subject: preview native x86_64 openoffice.org rpms In-Reply-To: <1140705683.11992.3.camel@localhost.localdomain> References: <1140705683.11992.3.camel@localhost.localdomain> Message-ID: <43FDD05C.5090103@hhs.nl> Caolan McNamara wrote: > rpms of a native x86_64 version of openoffice.org as created by the OOo > build process (680_m157/i.e. in fedora parlance equivalent to > 2.0.3-0.157) > at http://people.redhat.com/caolanm/x86_64/ > > "binfilter", i.e. support for legacy binary StarOffice support is > disabled, but everything else is in there. Seems to work ok :-), though > there might be nasties in there. > > C. > Woa, cool great job (to all involved)! Haven't tried it yett but I'll install it and feed it some large documents when I find the time. Regards, Hans From paul at all-the-johnsons.co.uk Thu Feb 23 15:10:38 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Thu, 23 Feb 2006 15:10:38 +0000 Subject: preview native x86_64 openoffice.org rpms In-Reply-To: <1140705683.11992.3.camel@localhost.localdomain> References: <1140705683.11992.3.camel@localhost.localdomain> Message-ID: <1140707438.6787.23.camel@mrwibble.mrwobble> Hi, > rpms of a native x86_64 version of openoffice.org as created by the OOo > build process (680_m157/i.e. in fedora parlance equivalent to > 2.0.3-0.157) > at http://people.redhat.com/caolanm/x86_64/ Excellent. > "binfilter", i.e. support for legacy binary StarOffice support is > disabled, but everything else is in there. Seems to work ok :-), though > there might be nasties in there. Other than it trashing oowriter etc in /usr/bin and installing in /opt, it looks okay so far. If it fails, do you want it filing under x86_64 OOo? TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From caolanm at redhat.com Thu Feb 23 15:13:02 2006 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 23 Feb 2006 15:13:02 +0000 Subject: preview native x86_64 openoffice.org rpms In-Reply-To: <1140707438.6787.23.camel@mrwibble.mrwobble> References: <1140705683.11992.3.camel@localhost.localdomain> <1140707438.6787.23.camel@mrwibble.mrwobble> Message-ID: <1140707582.11992.8.camel@localhost.localdomain> On Thu, 2006-02-23 at 15:10 +0000, Paul F. Johnson wrote: > Hi, > > > rpms of a native x86_64 version of openoffice.org as created by the OOo > > build process (680_m157/i.e. in fedora parlance equivalent to > > 2.0.3-0.157) > > at http://people.redhat.com/caolanm/x86_64/ > > Excellent. > > > "binfilter", i.e. support for legacy binary StarOffice support is > > disabled, but everything else is in there. Seems to work ok :-), though > > there might be nasties in there. > > Other than it trashing oowriter etc in /usr/bin and installing in /opt, > it looks okay so far. If it fails, do you want it filing under x86_64 > OOo? No, I'm not interested in packaging bugs, these are rpms from the OOo build process, not "proper" distro rpms :-) C. From michael.favia at insitesinc.com Thu Feb 23 15:16:30 2006 From: michael.favia at insitesinc.com (Michael Favia) Date: Thu, 23 Feb 2006 09:16:30 -0600 Subject: Ralink rt2500, can't load module In-Reply-To: <43FD62ED.7070701@vip.hr> References: <43FB7DC9.8060307@vip.hr> <1140559789.3082.37.camel@laptopd505.fenrus.org> <1140591640.2284.13.camel@aurora.localdomain> <43FCDA81.80703@vip.hr> <43FCFBE3.9030801@insitesinc.com> <43FD62ED.7070701@vip.hr> Message-ID: <43FDD1CE.5000208@insitesinc.com> Igor Jagec wrote: > Michael Favia wrote: > >> Igor Jagec wrote: >>> http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?p=6906 >> I saw your patch and tried to apply it. It was able to build but failed >> to insert the module. I updated to fresh CVS this afternoon and I had >> '/var/log/message' complaints on the ifname parameter sections (when >> modprobe'd) so i just commented out lines 61 and 62 also removed the > > In static_debug_parm.php file? > >> ifname option line from /etc/modules.conf. > > In /etc/modules.conf? Or /etc/modprobe.conf? Yes. Sorry bad with names and rely on TAB completion ALOT apparently. >> Obviously not the preferred >> solution but i am at least on the internet on this testing machine. -mf > > The same problem here after I succesfully applied the patch. Could you > copy/paste the lines 61 and 62 here? Is that it: > > // > -extern int debug; And no in rtmp_main.c Just look for the PARAM lines. See very small attached patch. Please just msg me with any further questions no need to trouble list. -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rt2500noIfnamePatch.txt URL: From paul at all-the-johnsons.co.uk Thu Feb 23 15:19:49 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Thu, 23 Feb 2006 15:19:49 +0000 Subject: preview native x86_64 openoffice.org rpms In-Reply-To: <1140707582.11992.8.camel@localhost.localdomain> References: <1140705683.11992.3.camel@localhost.localdomain> <1140707438.6787.23.camel@mrwibble.mrwobble> <1140707582.11992.8.camel@localhost.localdomain> Message-ID: <1140707989.6787.26.camel@mrwibble.mrwobble> Hi, > > Other than it trashing oowriter etc in /usr/bin and installing in /opt, > > it looks okay so far. If it fails, do you want it filing under x86_64 > > OOo? > > No, I'm not interested in packaging bugs, these are rpms from the OOo > build process, not "proper" distro rpms :-) So far the only four I've found are minor 1. It gives some strange errors when you first fire it up about importing previous version information - it's looking in the OOo 1.1.3 directories instead of the 2.0 ones 2. The default font has changed from the one I set up in the "proper" distro rpms (I have it set on Arial) 3. It has decided to default the dictionary back to the US one rather than the one I had set (English). 4. As I'm learning German, I had the UI set to German. It's now in English. This could be down to a langpack problem though. I doubt any of these warrant a BZ entry. TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From gilboad at gmail.com Thu Feb 23 15:27:37 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 23 Feb 2006 17:27:37 +0200 Subject: preview native x86_64 openoffice.org rpms In-Reply-To: <1140705683.11992.3.camel@localhost.localdomain> References: <1140705683.11992.3.camel@localhost.localdomain> Message-ID: <1140708457.7137.17.camel@gilboa-work-dev> On Thu, 2006-02-23 at 14:41 +0000, Caolan McNamara wrote: > rpms of a native x86_64 version of openoffice.org as created by the OOo > build process (680_m157/i.e. in fedora parlance equivalent to > 2.0.3-0.157) > at http://people.redhat.com/caolanm/x86_64/ > > "binfilter", i.e. support for legacy binary StarOffice support is > disabled, but everything else is in there. Seems to work ok :-), though > there might be nasties in there. > > C. > Yeeeeyyyyy! At last! Any chance of getting a FC4 back-port? (I can't afford to go FC5T on my x86_64 machine) Gilboa From caolanm at redhat.com Thu Feb 23 15:30:21 2006 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 23 Feb 2006 15:30:21 +0000 Subject: preview native x86_64 openoffice.org rpms In-Reply-To: <1140707989.6787.26.camel@mrwibble.mrwobble> References: <1140705683.11992.3.camel@localhost.localdomain> <1140707438.6787.23.camel@mrwibble.mrwobble> <1140707582.11992.8.camel@localhost.localdomain> <1140707989.6787.26.camel@mrwibble.mrwobble> Message-ID: <1140708622.11992.16.camel@localhost.localdomain> On Thu, 2006-02-23 at 15:19 +0000, Paul F. Johnson wrote: > 1. It gives some strange errors when you first fire it up about > importing previous version information - it's looking in the OOo 1.1.3 > directories instead of the 2.0 ones > 2. The default font has changed from the one I set up in the "proper" > distro rpms (I have it set on Arial) Normal, as a dev package it believes itself to be a different beast to 2.0.X and gives the stock "walk through import and register waffle" of an upstream build and it's own separate settings dir > 3. It has decided to default the dictionary back to the US one rather > than the one I had set (English). > 4. As I'm learning German, I had the UI set to German. It's now in > English. This could be down to a langpack problem though. Yeah, this is also normal. Only en_US support is in that package. > I doubt any of these warrant a BZ entry. What you need to look out for is "ka-boom", or more likely graphics and other binary or xml formats importing and exporting causing hangs or exported documents not possible to open on another platform. C. From rdieter at math.unl.edu Thu Feb 23 15:43:04 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 23 Feb 2006 09:43:04 -0600 Subject: preview native x86_64 openoffice.org rpms In-Reply-To: <1140708457.7137.17.camel@gilboa-work-dev> References: <1140705683.11992.3.camel@localhost.localdomain> <1140708457.7137.17.camel@gilboa-work-dev> Message-ID: <43FDD808.7040906@math.unl.edu> Gilboa Davara wrote: > On Thu, 2006-02-23 at 14:41 +0000, Caolan McNamara wrote: >> rpms of a native x86_64 version of openoffice.org as created by the OOo >> build process (680_m157/i.e. in fedora parlance equivalent to >> 2.0.3-0.157) >> at http://people.redhat.com/caolanm/x86_64/ >> >> "binfilter", i.e. support for legacy binary StarOffice support is >> disabled, but everything else is in there. Seems to work ok :-), though >> there might be nasties in there. > Yeeeeyyyyy! At last! > > Any chance of getting a FC4 back-port? > (I can't afford to go FC5T on my x86_64 machine) I'd bet these will work on FC4. (Or did you try, and fail?) -- Rex From pjones at redhat.com Thu Feb 23 06:38:59 2006 From: pjones at redhat.com (Peter Jones) Date: Thu, 23 Feb 2006 01:38:59 -0500 Subject: Results for install and remove tests for FC-Devel In-Reply-To: <43FC7E02.1000705@volny.cz> References: <43FC3ECA.9020100@redhat.com> <20060222140044.GA2959@free.fr> <43FC7E02.1000705@volny.cz> Message-ID: <1140676740.15913.3.camel@localhost.localdomain> On Wed, 2006-02-22 at 16:06 +0100, Miloslav Trmac wrote: > Patrice Dumas napsal(a): > > I may be completely wrong, but couldn't it be assumed that > > coreutils is always installed? A linux system without rm doesn't > > make much sense... > Not during installation :) anaconda uses package dependencies to order > the package installation correctly. Yeah, but coreutils is a mandatory component of the "core" group in comps. It will always be at the top of the input to tsort, and tsort won't move it later except when it's inserting something above it to satisfy a coreutils (or the 4 packages in front of it) dependency. -- Peter From caolanm at redhat.com Thu Feb 23 15:38:57 2006 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 23 Feb 2006 15:38:57 +0000 Subject: preview native x86_64 openoffice.org rpms In-Reply-To: <1140708457.7137.17.camel@gilboa-work-dev> References: <1140705683.11992.3.camel@localhost.localdomain> <1140708457.7137.17.camel@gilboa-work-dev> Message-ID: <1140709138.11992.24.camel@localhost.localdomain> On Thu, 2006-02-23 at 17:27 +0200, Gilboa Davara wrote: > On Thu, 2006-02-23 at 14:41 +0000, Caolan McNamara wrote: > > rpms of a native x86_64 version of openoffice.org as created by the OOo > > build process (680_m157/i.e. in fedora parlance equivalent to > > 2.0.3-0.157) > > at http://people.redhat.com/caolanm/x86_64/ > > > > "binfilter", i.e. support for legacy binary StarOffice support is > > disabled, but everything else is in there. Seems to work ok :-), though > > there might be nasties in there. > > > > C. > > > > Yeeeeyyyyy! At last! > > Any chance of getting a FC4 back-port? Not a chance of a supported version, though those packages were built on my x86_64 fc4 box. > (I can't afford to go FC5T on my x86_64 machine) It won't be in FC5 either. There's absolutely no chance that it's bug-free :-), and fixing the binfilter work will take a while to complete anyway. There might be fedora tuned src.rpms at a later date which will be buildable on x86_64 fc4/fc5 for those interesting in trying those out for themselves instead. C. From Eric.Tanguy at univ-nantes.fr Thu Feb 23 15:43:32 2006 From: Eric.Tanguy at univ-nantes.fr (Eric TANGUY) Date: Thu, 23 Feb 2006 16:43:32 +0100 (CET) Subject: Ralink rt2500, can't load module In-Reply-To: <1140681626.4681.13.camel@aurora.localdomain> References: <43FB7DC9.8060307@vip.hr> <1140559789.3082.37.camel@laptopd505.fenrus.org> <1140591640.2284.13.camel@aurora.localdomain> <1140644675.3119.4.camel@bureau.maison> <1140681626.4681.13.camel@aurora.localdomain> Message-ID: <51067.193.52.109.12.1140709412.squirrel@webmail.univ-nantes.fr> I found it in the forum : http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=675&start=0&postdays=0&postorder=asc&highlight= But it seems to not be relevant to this problem : "That topic is about the rt2x00 driver not the legacy driver. And the patch was not for rt2x00 but for the ieee80211 stack." Eric > No, that is not it. I no longer have the book mark, but it was in the > support forums (vichu is the user name). I cannot remember which team > member was reading my comments. They fixed up the USB part but didn't > fix up the module_param stuff. Basically, in newer kernels, this has > changed and the latest one now has depricated the older method. instead > of "i" or what not for type it is int. Beyond that, I cannot remember > what the changes were. > > Trever > > On Wed, 2006-02-22 at 22:44 +0100, Eric Tanguy wrote: >> Le mercredi 22 f??vrier 2006 ?? 00:00 -0700, Trever L. Adams a ??crit : >> > This is a bug in rt2500. I reported it. It has to do with module_param >> > call not following the new standard. They have not fixed this problem >> > even though I reported it with a fix. I patched my own but am no >> longer >> > using the card (though when master mode works I will switch back due >> to >> > my preference for completely open source drivers instead of partially >> > one way or the other. >> > >> > I suggest you ask them to fix it up for newer kernels. The problem is >> in >> > their MODULE_PARAM calls. >> > >> > Trever >> > >> > On Tue, 2006-02-21 at 23:09 +0100, Arjan van de Ven wrote: >> > > On Tue, 2006-02-21 at 21:53 +0100, Igor Jagec wrote: >> > > > I compiled beta3 and cvs drivers on FC5t3 and everything went ok, >> but >> > > > the rt2500 module can't be loaded. On FC5t2's default kernel >> everything >> > > > went ok (both, compiling and loading the rt2500 module). >> > > > >> > > > [root at localhost Module]# /sbin/modprobe rt2500 >> > > > FATAL: Error inserting rt2500 >> > > > (/lib/modules/2.6.15-1.1955_FC5/extra/rt2500.ko): Invalid argument >> > > >> > > look in dmesg output for a more descriptive reason for the failure >> > > >> > -- >> > "He who chops his own wood, is warm twice." -- Abraham Lincoln >> > >> This is the report you speak about ? >> http://sourceforge.net/tracker/index.php?func=detail&aid=1427910&group_id=107832&atid=648846 >> If yes could you answer questions asked for the final submission ? >> If not could you give us the link to the report you did, please ? >> Thanks >> Eric >> >> > -- > "Magazines all too frequently lead to books and should be regarded by > the prudent as the heavy petting of literature." -- Fran Lebowitz > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From gilboad at gmail.com Thu Feb 23 15:40:23 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 23 Feb 2006 17:40:23 +0200 Subject: preview native x86_64 openoffice.org rpms In-Reply-To: <43FDD808.7040906@math.unl.edu> References: <1140705683.11992.3.camel@localhost.localdomain> <1140708457.7137.17.camel@gilboa-work-dev> <43FDD808.7040906@math.unl.edu> Message-ID: <1140709223.7137.20.camel@gilboa-work-dev> On Thu, 2006-02-23 at 09:43 -0600, Rex Dieter wrote: > Gilboa Davara wrote: > > On Thu, 2006-02-23 at 14:41 +0000, Caolan McNamara wrote: > >> rpms of a native x86_64 version of openoffice.org as created by the OOo > >> build process (680_m157/i.e. in fedora parlance equivalent to > >> 2.0.3-0.157) > >> at http://people.redhat.com/caolanm/x86_64/ > >> > >> "binfilter", i.e. support for legacy binary StarOffice support is > >> disabled, but everything else is in there. Seems to work ok :-), though > >> there might be nasties in there. > > > Yeeeeyyyyy! At last! > > > > Any chance of getting a FC4 back-port? > > (I can't afford to go FC5T on my x86_64 machine) > > I'd bet these will work on FC4. (Or did you try, and fail?) > > -- Rex > /me bang head into desk for failing to read the OP message. I'll give'em a try later today. (When I get back home) Gilboa From chitlesh at fedoraproject.org Thu Feb 23 15:49:16 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 23 Feb 2006 16:49:16 +0100 Subject: python and rpm Message-ID: <13dbfe4f0602230749o277329ffu1754b4eaa7826c1e@mail.gmail.com> hai there i got a question related with rpm for mi in ts.dbMatch ('name', 'kernel'): it searches for kernel good. now I want it to search for 'hypervisor' ? it is not a 'release' how should i proceed? -- http://clunixchit.blogspot.com From pknirsch at redhat.com Thu Feb 23 15:51:09 2006 From: pknirsch at redhat.com (Phil Knirsch) Date: Thu, 23 Feb 2006 16:51:09 +0100 Subject: Results for install and remove tests for FC-Devel In-Reply-To: <1140676740.15913.3.camel@localhost.localdomain> References: <43FC3ECA.9020100@redhat.com> <20060222140044.GA2959@free.fr> <43FC7E02.1000705@volny.cz> <1140676740.15913.3.camel@localhost.localdomain> Message-ID: <43FDD9ED.7040507@redhat.com> Peter Jones wrote: > On Wed, 2006-02-22 at 16:06 +0100, Miloslav Trmac wrote: >> Patrice Dumas napsal(a): >>> I may be completely wrong, but couldn't it be assumed that >>> coreutils is always installed? A linux system without rm doesn't >>> make much sense... >> Not during installation :) anaconda uses package dependencies to order >> the package installation correctly. > > Yeah, but coreutils is a mandatory component of the "core" group in > comps. It will always be at the top of the input to tsort, and tsort > won't move it later except when it's inserting something above it to > satisfy a coreutils (or the 4 packages in front of it) dependency. > Absolutely true, thats why i said those errors are really just for completeness as real installations always have to install those components. The other errors though like chkconfig and the other prereqs on the other hand are "real" errors in the sense that chkconfig isn't anywhere to be found in comps.xml and only gets pulled in if it's really required. 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 paul at all-the-johnsons.co.uk Thu Feb 23 15:54:24 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Thu, 23 Feb 2006 15:54:24 +0000 Subject: preview native x86_64 openoffice.org rpms In-Reply-To: <1140708622.11992.16.camel@localhost.localdomain> References: <1140705683.11992.3.camel@localhost.localdomain> <1140707438.6787.23.camel@mrwibble.mrwobble> <1140707582.11992.8.camel@localhost.localdomain> <1140707989.6787.26.camel@mrwibble.mrwobble> <1140708622.11992.16.camel@localhost.localdomain> Message-ID: <1140710064.6787.30.camel@mrwibble.mrwobble> Hi, > > I doubt any of these warrant a BZ entry. > > What you need to look out for is "ka-boom", or more likely graphics and > other binary or xml formats importing and exporting causing hangs or > exported documents not possible to open on another platform. I've got two ka-boom-ers here :-) One is a oowriter file with png inside of a frame. It causes OOo to completely hang (100% processor use), the other is a file with a hell of a lot of maths formulae in (the progress bar says that it's adapting objects and then falls over with 100% processor use). Do you want them BZ'd or just emailed to you off list? TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From david at fubar.dk Thu Feb 23 16:01:03 2006 From: david at fubar.dk (David Zeuthen) Date: Thu, 23 Feb 2006 11:01:03 -0500 Subject: Hotplug: no more fstab entries In-Reply-To: <1140703661.23024.46.camel@golem.boston.redhat.com> References: <20060222153244.002ea18c@dhcp05.addix.net> <43FC978E.6040006@feuerpokemon.de> <43FCB30D.2020509@unb.ca> <604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com> <20060223103910.2d9874ae@dhcp05.addix.net> <1140703661.23024.46.camel@golem.boston.redhat.com> Message-ID: <1140710463.24114.1.camel@daxter.boston.redhat.com> On Thu, 2006-02-23 at 09:07 -0500, Matthias Clasen wrote: > Last time I looked, gnome-mount was only using GTK+. I think gnome-mount (pre 0.4 CVS snapshot) in Rawhide currently only requires GTK+. Upstream (what will be 0.4) currently pulls in libgnomeui and libgnome-keyring for passworded media. David From paul at all-the-johnsons.co.uk Thu Feb 23 16:02:12 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Thu, 23 Feb 2006 16:02:12 +0000 Subject: preview native x86_64 openoffice.org rpms In-Reply-To: <1140708622.11992.16.camel@localhost.localdomain> References: <1140705683.11992.3.camel@localhost.localdomain> <1140707438.6787.23.camel@mrwibble.mrwobble> <1140707582.11992.8.camel@localhost.localdomain> <1140707989.6787.26.camel@mrwibble.mrwobble> <1140708622.11992.16.camel@localhost.localdomain> Message-ID: <1140710532.6787.32.camel@mrwibble.mrwobble> Hi, > What you need to look out for is "ka-boom", or more likely graphics and > other binary or xml formats importing and exporting causing hangs or > exported documents not possible to open on another platform. Try inserting a maths formulae (something like an integral so that it appears on screen as oomaths) and watch oowriter go kaplooey! TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From david at fubar.dk Thu Feb 23 16:04:17 2006 From: david at fubar.dk (David Zeuthen) Date: Thu, 23 Feb 2006 11:04:17 -0500 Subject: Hotplug: no more fstab entries In-Reply-To: <604aa7910602230608r34dfc1a1r17abe661f0b0dc9b@mail.gmail.com> References: <20060222153244.002ea18c@dhcp05.addix.net> <43FC978E.6040006@feuerpokemon.de> <43FCB30D.2020509@unb.ca> <604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com> <20060223103910.2d9874ae@dhcp05.addix.net> <1140698854.3633.1.camel@daxter.boston.redhat.com> <20060223141925.5a085d71@dhcp05.addix.net> <1140701508.3633.9.camel@daxter.boston.redhat.com> <604aa7910602230608r34dfc1a1r17abe661f0b0dc9b@mail.gmail.com> Message-ID: <1140710657.24114.6.camel@daxter.boston.redhat.com> On Thu, 2006-02-23 at 09:08 -0500, Jeff Spaleta wrote: > On 2/23/06, David Zeuthen wrote: > > http://freedesktop.org/~david/gnome-mount-properties-0.01.png > > > > for some work in progress. > > Is there be a cmdline oriented tool planned to do what the gui > gnome-mount-properties does to balance the functionality of > gnome-mount on the cmdline? Or will we be asked to use gconftool to > edit these keys from the cmdline? No command-line tools are planned but I can't see why we couldn't provide these if someone stepped up to the task and wrote the code. Seriously, nothing is set in stone yet. I've already tried to encourage people on this list to send patches but I have not received any yet. David From notting at redhat.com Thu Feb 23 16:05:18 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 23 Feb 2006 11:05:18 -0500 Subject: Hotplug: no more fstab entries In-Reply-To: <1140701508.3633.9.camel@daxter.boston.redhat.com> References: <20060222153244.002ea18c@dhcp05.addix.net> <43FC978E.6040006@feuerpokemon.de> <43FCB30D.2020509@unb.ca> <604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com> <20060223103910.2d9874ae@dhcp05.addix.net> <1140698854.3633.1.camel@daxter.boston.redhat.com> <20060223141925.5a085d71@dhcp05.addix.net> <1140701508.3633.9.camel@daxter.boston.redhat.com> Message-ID: <20060223160518.GA13799@devserv.devel.redhat.com> David Zeuthen (david at fubar.dk) said: > > Can I restore the old behaviour somehow? > > Not really, no. But nothing prevents you from write an fstab-sync like > program yourself and submitting it to Fedora Extras. That's a cheat, though - the introduction is removing functionality from the OS. This is all documented in the release notes, right? Bill From monpetitbeurre at gmail.com Thu Feb 23 16:09:04 2006 From: monpetitbeurre at gmail.com (Nic) Date: Thu, 23 Feb 2006 10:09:04 -0600 Subject: Fwd: Stateless linux and an idea of mine for SMALL networks without servers In-Reply-To: References: Message-ID: (I had been trying to send this email without much success. Sorry if you got it twice) I hope that this is the right mailing list, but I really wanted to reach developers would can say if it's feasible and what to use for that. Anyway, I was fighting the usual problems with networks and came up with the following idea (pipe dream?) to make my life easier as a network admin. Basically I am tired of fixing things, of worrying if a hard disk will die, of having to deal with data access, backup etc... I was thinking this through by looking at how most of my coworkers, friends, and small offices use their PCs in day-to-day operations and applying that work flow to a solution. Before, somebody screams, this means little or moderate daily data generation so that, basically, a laptop drive could hold the entire company's data. (This may require email-purge rules and other things like that). Anyway here it is: Basically, I suggest that (almost) all PCs in the network be laptops with the exact same image. Furthermore, they replicate their HD continuously (with possibly some delay). This certainly applies to the user data and application. It may not be necessary for the OS I am not sure of the technology to use here, but I thought something deriving from the P-to-P technology, some distributed file system, some database replication technology or even freenet could be a good base. Since every laptop will contain ALL the data for the whole network, every laptop uses hardware encryption at the hard disk level using an external dongle/card/whatever to limit the risk when a laptop is lost or stolen. Additionally, every login ALSO uses a dongle/card for access to their account. This makes it (almost) impossible for somebody stealing a laptop to get access to the whole data. Additionally, it makes it (alomst) impossible for somebody to fet to other people's data. If a system dies, you just get a new one and sync it up. However, one main idea is that you always have EVERYTHING you need right where you are, no matter WHERE you are. Also, there is no UPS to worry about. Communication between PCs could be implemented using VPN/IPSec or whatever other protected mechanism. Internet access would have to be "sandboxed", but UNIX based OSes allow for that easily. That's the gist of it. A lot of things can be configured in many ways, but the whole point here is to simplify people's life. Look at it from a disaster recovery: a lot of people bring their laptop home. Even if the company's building burns down as well as a few employees homes, one surviving laptop is enough to bring the business back online. Pros: * seamless company disaster recovery * seamless personal computer loss recovery (you lose everything since the last sync) * you can use ANY laptop and find YOUR own environment and files * no central server/single point of failure * no UPS except for the internet firewall (this comes from the PCs being laptops) Cons: * sync across a lot of PCs might be tricky and needs to be tuned. Maybe randonly select one as master like the SMB Master browser election works? * each laptop needs to have enough space for the whole company's data * maybe not appropriate for disk intensive applications (video capture...) I wanted to post it here for other people to use if they think it's a good idea. (and also to preempt any proprietary company from saying "me first") It seems that Windows Vista is coming with some automatic synchronization across two PCs so, that's one step towards it, but we have different goals. I posted this somewhere and somebody pointed me toward stateless linux and it seems pretty cool and close to what I was thinking of. I'll look some more into it, but does anybody see this as useful for VERY SMALL networks? (I already got bashed by enterprise admins sneering at people who don't want a rack server, so if that's your intent, just reply "me too"). Feel free to comment. Nick From david at fubar.dk Thu Feb 23 16:18:11 2006 From: david at fubar.dk (David Zeuthen) Date: Thu, 23 Feb 2006 11:18:11 -0500 Subject: Hotplug: no more fstab entries In-Reply-To: <20060223160518.GA13799@devserv.devel.redhat.com> References: <20060222153244.002ea18c@dhcp05.addix.net> <43FC978E.6040006@feuerpokemon.de> <43FCB30D.2020509@unb.ca> <604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com> <20060223103910.2d9874ae@dhcp05.addix.net> <1140698854.3633.1.camel@daxter.boston.redhat.com> <20060223141925.5a085d71@dhcp05.addix.net> <1140701508.3633.9.camel@daxter.boston.redhat.com> <20060223160518.GA13799@devserv.devel.redhat.com> Message-ID: <1140711491.24114.18.camel@daxter.boston.redhat.com> On Thu, 2006-02-23 at 11:05 -0500, Bill Nottingham wrote: > David Zeuthen (david at fubar.dk) said: > > > Can I restore the old behaviour somehow? > > > > Not really, no. But nothing prevents you from write an fstab-sync like > > program yourself and submitting it to Fedora Extras. > > That's a cheat, though - the introduction is removing functionality from > the OS. Strong disagreement. You can use gnome-mount and/or mount(1) - they work just fine and gnome-mount will (at least in the future) do so much more than we could ever do with the fstab-sync approach. KDE also got some stuff for this but I don't follow KDE development very closely, sorry. You can also use dbus-send in conjunction with hal-find-by-property... it's not exactly rocket science [davidz at daxter ~]$ dbus-send --system --dest=org.freedesktop.Hal --print-reply /org/freedesktop/Hal/devices/volume_uuid_43F1_517C org.freedesktop.Hal.Device.Volume.Unmount array:string: method return sender=:1.2 -> dest=:1.62 uint32 0 [davidz at daxter ~]$ dbus-send --system --dest=org.freedesktop.Hal --print-reply /org/freedesktop/Hal/devices/volume_uuid_43F1_517C org.freedesktop.Hal.Device.Volume.Mount string: string: array:string: method return sender=:1.2 -> dest=:1.65 uint32 0 Seriously, if someone really cared about this they would sit down and write two 20-lines shell script so you could do 'hal-mount /dev/sda1' and 'hal-umount /dev/sda1'. I'm really tired of people complaining without doing. > This is all documented in the release notes, right? If you think it's necessary.. feel free to add it. David From eric at interplas.com Thu Feb 23 16:40:48 2006 From: eric at interplas.com (Eric Wood) Date: Thu, 23 Feb 2006 11:40:48 -0500 Subject: gnome 2.14 after FC5 released? Message-ID: <01f801c63897$e69a3200$f502000a@M145Primary> Since the release dates for gnome 2.14 and FC5 are the same, and the devel freeze is even earlier, will the gnome 2.14 probably be released as an update? I know there was some talk about sliding FC5 just for the sake of gnome 2.14 and it performance benefits. I was just wondering what the latest concensus was. -eric wood From jspaleta at gmail.com Thu Feb 23 16:40:53 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 23 Feb 2006 11:40:53 -0500 Subject: Hotplug: no more fstab entries In-Reply-To: <1140711491.24114.18.camel@daxter.boston.redhat.com> References: <20060222153244.002ea18c@dhcp05.addix.net> <43FC978E.6040006@feuerpokemon.de> <43FCB30D.2020509@unb.ca> <604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com> <20060223103910.2d9874ae@dhcp05.addix.net> <1140698854.3633.1.camel@daxter.boston.redhat.com> <20060223141925.5a085d71@dhcp05.addix.net> <1140701508.3633.9.camel@daxter.boston.redhat.com> <20060223160518.GA13799@devserv.devel.redhat.com> <1140711491.24114.18.camel@daxter.boston.redhat.com> Message-ID: <604aa7910602230840t3805e76cq4e30630883b90c60@mail.gmail.com> On 2/23/06, David Zeuthen wrote: > You can also use dbus-send in conjunction with hal-find-by-property... > it's not exactly rocket science If I had a better personal understanding of the capabilities of the dbus commandline tools like dbus-send that would help. Are there existing examples of dbus-send usage that do useful work in the wild? I honestly do not grok dbus communication well enough to be able to parse the example you give usefully from a "get crap done with a shell script" sysadmin point of view. And the errors spawned the what I assume to be non-functional example in the dbus-send on the fc4 manpage leaves my mouth agape and my eyes glassy. If you know of something better than http://dbus.freedesktop.org/doc/dbus-tutorial.html to help sysadmins learn enough about dbus to use dbus-send effectively please let me know. Especially any existing generally useful scripts that exist to do useful work. -jef From orion at cora.nwra.com Thu Feb 23 16:35:41 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 23 Feb 2006 09:35:41 -0700 Subject: Any ppc netboot install instructions out there? Message-ID: I'm pretty new to the ppc architecture and really have no clue how to start a kickstart install on a ppc Mac via network (PXE? netboot?) start. I do PXE installs on x86 all the time... - Orion From mailinglists at erwinrol.com Thu Feb 23 16:43:05 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Thu, 23 Feb 2006 17:43:05 +0100 Subject: eclipse Message-ID: <1140712986.24563.15.camel@xpc.home.erwinrol.com> Hey all, I tried to use eclipse for a C++ project but after liek 10 crashes in the last 30 minutes i kind of gave up. My question; is there anybody out there that actually uses eclipse ? And with uses i mean like working with it 8 hours a day without a crash ever 5 minutes. BTW: this is on x86_64 and FC5. - Erwin From aph at redhat.com Thu Feb 23 16:47:47 2006 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Feb 2006 16:47:47 +0000 Subject: eclipse In-Reply-To: <1140712986.24563.15.camel@xpc.home.erwinrol.com> References: <1140712986.24563.15.camel@xpc.home.erwinrol.com> Message-ID: <17405.59187.735975.485189@zapata.pink> Erwin Rol writes: > Hey all, > > I tried to use eclipse for a C++ project but after liek 10 crashes in > the last 30 minutes i kind of gave up. > > My question; is there anybody out there that actually uses eclipse ? And > with uses i mean like working with it 8 hours a day without a crash ever > 5 minutes. > > BTW: this is on x86_64 and FC5. Well, FC5 isn't actually released yet, and I'm aware of at least one problem with Eclipse. Let us know what your problems are. Andrew. From orion at cora.nwra.com Thu Feb 23 16:48:16 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 23 Feb 2006 09:48:16 -0700 Subject: Results for install and remove tests for FC-Devel In-Reply-To: <1140676740.15913.3.camel@localhost.localdomain> References: <43FC3ECA.9020100@redhat.com> <20060222140044.GA2959@free.fr> <43FC7E02.1000705@volny.cz> <1140676740.15913.3.camel@localhost.localdomain> Message-ID: Peter Jones wrote: > Yeah, but coreutils is a mandatory component of the "core" group in > comps. It will always be at the top of the input to tsort, and tsort > won't move it later except when it's inserting something above it to > satisfy a coreutils (or the 4 packages in front of it) dependency. > comps is gone. It's all yum depsolver ordering now. I just did a fresh install of FC5T3 and avahi was installed before coreutils, and thus the post script broke. A bug has been filed against avahi. From pknirsch at redhat.com Thu Feb 23 16:53:50 2006 From: pknirsch at redhat.com (Phil Knirsch) Date: Thu, 23 Feb 2006 17:53:50 +0100 Subject: Results for install and remove tests for FC-Devel In-Reply-To: References: <43FC3ECA.9020100@redhat.com> <20060222140044.GA2959@free.fr> <43FC7E02.1000705@volny.cz> <1140676740.15913.3.camel@localhost.localdomain> Message-ID: <43FDE89E.4040002@redhat.com> Orion Poplawski wrote: > Peter Jones wrote: >> Yeah, but coreutils is a mandatory component of the "core" group in >> comps. It will always be at the top of the input to tsort, and tsort >> won't move it later except when it's inserting something above it to >> satisfy a coreutils (or the 4 packages in front of it) dependency. >> > > comps is gone. It's all yum depsolver ordering now. I just did a fresh > install of FC5T3 and avahi was installed before coreutils, and thus the > post script broke. A bug has been filed against avahi. > > Something else must be broken then: rpm -q --requires avahi -> python rpm -q --requires python -> /usr/bin/env rpm -qf /usr/bin/env -> coreutils So avahi has a chained requirement on coreutils via python and coreutils has to be installed prior to python which in turn has to be installed prior to avahi. Did you do an anaconda install resp. how did you get this error? 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 lamont at gurulabs.com Thu Feb 23 16:58:15 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Thu, 23 Feb 2006 09:58:15 -0700 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <6280325c0602230010w7f46f8b0gc3592e14fb5b6ddb@mail.gmail.com> References: <43FD0AC0.2090702@redhat.com> <43FD6CED.9040703@vip.hr> <6280325c0602230010w7f46f8b0gc3592e14fb5b6ddb@mail.gmail.com> Message-ID: <200602230958.19039.lamont@gurulabs.com> On Thursday 23 February 2006 01:10am, n0dalus wrote: > On 2/23/06, Igor Jagec wrote: [snip] > Essentially, after installing livna's packages instead, you would need > to do an rpm -Va on various packages to ensure that the files hadn't > been replaced (If they have, reinstall those packages). Not to nit-pick, but running rpm -Va will check *all* packages; that's what the -a switch does. Same for rpm -qa listing all packages. Of course, you can also do: rpm -qa kernel* to see all packages that begin with "kernel". If you want to verify only certain packages with rpm, run: rpm -V package1 package2 package3 BTW: rpm -Va will take a long time to run. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From overholt at redhat.com Thu Feb 23 17:04:57 2006 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 23 Feb 2006 12:04:57 -0500 Subject: eclipse In-Reply-To: <1140712986.24563.15.camel@xpc.home.erwinrol.com> References: <1140712986.24563.15.camel@xpc.home.erwinrol.com> Message-ID: <20060223170456.GC18677@redhat.com> * Erwin Rol [2006-02-23 11:43]: > > My question; is there anybody out there that actually uses eclipse ? And > with uses i mean like working with it 8 hours a day without a crash ever > 5 minutes. Well, "using Eclipse" can mean many, many different things. I use it all the time but not for C++. The CDT needs some love. I'm trying to give it some but it would really help if I had some specific bug reports. If you could file one or two, I'd really appreciate it. Thanks, Andrew From dwmw2 at infradead.org Thu Feb 23 17:06:25 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 23 Feb 2006 17:06:25 +0000 Subject: Any ppc netboot install instructions out there? In-Reply-To: References: Message-ID: <1140714385.22730.18.camel@pmac.infradead.org> On Thu, 2006-02-23 at 09:35 -0700, Orion Poplawski wrote: > I'm pretty new to the ppc architecture and really have no clue how to > start a kickstart install on a ppc Mac via network (PXE? netboot?) > start. I do PXE installs on x86 all the time... You just need to get OpenFirmware to tftp-boot the netboot image appropriate to your machine (ppc32.img or ppc64.img from images/netboot/ in the install tree). For instructions on getting OF to do that, try Google, or #mklinux or #fedora-ppc on FreeNode. I don't remember offhand how to do it on Macs. -- dwmw2 From jspaleta at gmail.com Thu Feb 23 17:08:12 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 23 Feb 2006 12:08:12 -0500 Subject: Hotplug: no more fstab entries In-Reply-To: <604aa7910602230840t3805e76cq4e30630883b90c60@mail.gmail.com> References: <20060222153244.002ea18c@dhcp05.addix.net> <43FCB30D.2020509@unb.ca> <604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com> <20060223103910.2d9874ae@dhcp05.addix.net> <1140698854.3633.1.camel@daxter.boston.redhat.com> <20060223141925.5a085d71@dhcp05.addix.net> <1140701508.3633.9.camel@daxter.boston.redhat.com> <20060223160518.GA13799@devserv.devel.redhat.com> <1140711491.24114.18.camel@daxter.boston.redhat.com> <604aa7910602230840t3805e76cq4e30630883b90c60@mail.gmail.com> Message-ID: <604aa7910602230908g760fbb79v884a5df6c7d7d243@mail.gmail.com> On 2/23/06, Jeff Spaleta wrote: > On 2/23/06, David Zeuthen wrote: > > You can also use dbus-send in conjunction with hal-find-by-property... > > it's not exactly rocket science > Actually since we are talking about scripting dbus actions with the cmdline tools... how do i get access to dbus's introspection ability via the cmdline tools so that as a sysadmin I can explore the object path and valid messages? -jef From lamont at gurulabs.com Thu Feb 23 17:19:15 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Thu, 23 Feb 2006 10:19:15 -0700 Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) In-Reply-To: <604aa7910602230634l5751103v11690aa4e241fcab@mail.gmail.com> References: <43FD0AC0.2090702@redhat.com> <604aa7910602230634l5751103v11690aa4e241fcab@mail.gmail.com> Message-ID: <200602231019.28227.lamont@gurulabs.com> On Thursday 23 February 2006 07:34am, Jeff Spaleta wrote: > On 2/23/06, Rudolf Kastl wrote: > > thats definitely a worst case scenario ;) > > And sadly the most likely one, until there are some end-user oriented > notifications from the system which explain what is going on and why, > when an selinux related denial happens. Having to keep a running tail > of /var/log/messages open and learning how to decipher the avc > messages while using vendor installers is a hurdle an order of > magnitude too large for normal home users who don't understand the > underlying issues. And sadly, reaching out to other users tends to > get you blanket "turn off" selinux answers. There is a steep learning > curve associated with selinux denials, and unless the fedora system > makes an attempt to point users to granular tools as the denials occur > the re-education effort is going to be hamstrung. By no means is this limited to home users. I would say that the *vast* majority of corporate admins just turn off SELinux. The story behind how & why they learned to do that to begin with only vary in details. It's almost always, "I had problems installing X or doing Y and I found a document on the Internet that said that SELinux was in the way and didn't work right anyway and was too complicated and didn't do me any good and that I couldn't learn enough about it to even understand what was happening, let alone deal with it, in less than a month and ... well, so I just turn off SELinux and then I don't have to deal with it." I teach Linux for a living. I teach Red Hat's courses and hear this story in almost every class taught. Students even ask me if they'll have to do SELinux in the RHCT/RHCE exams, and then cringe in anticipation that I'll reply, "Yes.". Of course, the only answer I can give is "I don't know; if it's in the book it could be on the exam." ;) You're right, there needs to be a buffer that makes SELinux troubleshooting and education less intimidating if we want end-users to keep SELinux enabled. I tell students in my classes that SELinux *is* intimidating and that they are not going to learn enough about it to write their own policy. But that they will learn enough to understand why SELinux is important and valuable and to be able to identify and fix the most common problems (missing labels, booleans that need flipping, etc.) so that they can keep their SELinux enabled systems running smoothly and that it's not as hard as they think. I also think that application developers need to think about SELinux when writing code. If they also helped (that's "helped", not "did all the work") in producing policy for their own app(s), it just might not "get in the way". This might be a pipe dream today; but, I remain hopeful. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From che666 at gmail.com Thu Feb 23 17:23:42 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 23 Feb 2006 18:23:42 +0100 Subject: Unite Non-free repos (Was: Re: Non-free Extras?) In-Reply-To: <1140641962.4192.102.camel@localhost.localdomain> References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> <43FC1F67.7080607@argo.co.il> <20060222120630.GD20029@devserv.devel.redhat.com> <43FC5A1B.4070106@cornell.edu> <43FCC1D2.4020206@gmail.com> <1140641962.4192.102.camel@localhost.localdomain> Message-ID: 2006/2/22, Thorsten Leemhuis : > Am Mittwoch, den 22.02.2006, 14:56 -0500 schrieb Eric Mesa: > >[...] > > The reason for my starting the thread was the fact that there are a > > myriad of repos out there for those of us who need (or "need" - > > depending on your point of view) access to non-free software. They > > overlap in a lot of places, but some have one app that others don't. > > That's true. > > > However, mixing repos who don't work together can have bad results. > > Yep. > > > So I was hoping we could unite them in, > > Well, "unite them" sounds like a good plan -- the current situation > creates a lot of confusing. Some users wandered off to Ubuntu due to > that. But there are some things that you can't unite. So it probably > needs to be a "unite what can be united". > > At least freshrpms and livna are close together regarding politics and > packages -- both do not replace or update packages from Core or Extras > (normally). Maybe it's time to forget all the old flamewars that > happened years ago and merge the two. Anvil, thias, what's your opinion? > I'm, willing to act as middle man for "merging discussions" if those two > accept me (Disclaimer: I contribute to livna, but I was not involved in > the flamewars in the pre-fedora.us days -- only some of those that > happened later). > > newrpms: che has a package under review from extras. He also does not > replace things from extras or livna normally. I'm optimistic that we > could get him involved in merge plans, too. > > atrpms and dag/dries/rpmforge: Depends on them. They currently replace > packages from Core and Extras -- that's necessary to achieve some things > they do (things Extras and Livna don't do), but a lot of people don't > like that. But there is no reason why they can't joins a merged > "Non-Free-Repo" (Let's call it "Repo-Which-Must-Not-Be-Named") and > continue the other stuff that does not harmonizes separately. But that's > probably more work for them with a small gain for them. Correct me if > I'm wrong. > > I didn't follow the other repos to closely -- maybe someone else can > comment on those? > > >say, the Fedora-non-free and > > Fedora-tricky-licensing repos so that they could work together and > > maintain package consistency, etc. > > We probably can't do the above (and shouldn't do that) under the name > "Fedora". Proprietary software (like the drivers from ati and nvidia) > and "Patent Encumbered" software is a no go for Fedora afaics. > > But yes, maybe we could to a "Fedora Extras Non-Free" for things like > - the Firmware for ipw2100 and ipw2200 > - stuff like povray -- open-source, but not "free" (see > https://www.redhat.com/archives/fedora-extras-list/2006-February/msg00191.html > for details) > > CU > thl > -- > Thorsten Leemhuis > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > well id be happy if just planetccrma would be slowly merged into extras... the main blocker seems to be the realtime kernel module as far as i can see. actually from the other repos only a few packages are missing that could be contributed to extras and youd be nearly there. besides some kernel modules atrpms provides e.g. regards, rudolf kastl From fedora at camperquake.de Thu Feb 23 17:26:37 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 23 Feb 2006 18:26:37 +0100 Subject: Hotplug: no more fstab entries In-Reply-To: <1140710463.24114.1.camel@daxter.boston.redhat.com> References: <20060222153244.002ea18c@dhcp05.addix.net> <43FC978E.6040006@feuerpokemon.de> <43FCB30D.2020509@unb.ca> <604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com> <20060223103910.2d9874ae@dhcp05.addix.net> <1140703661.23024.46.camel@golem.boston.redhat.com> <1140710463.24114.1.camel@daxter.boston.redhat.com> Message-ID: <20060223182637.689f602c@dhcp05.addix.net> Hi. On Thu, 23 Feb 2006 11:01:03 -0500, David Zeuthen wrote: > I think gnome-mount (pre 0.4 CVS snapshot) in Rawhide currently only > requires GTK+. Upstream (what will be 0.4) currently pulls in > libgnomeui and libgnome-keyring for passworded media. [sun at dhcp05 ~ :) 3]$ rpm -q gnome-mount gnome-mount-0.4-0.cvs20060213.1 [sun at dhcp05 ~ :) 4]$ ldd /usr/bin/gnome-mount linux-gate.so.1 => (0x007f8000) libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2 (0x06295000) libhal-storage.so.1 => /usr/lib/libhal-storage.so.1 (0x00dec000) libhal.so.1 => /usr/lib/libhal.so.1 (0x0625e000) libdbus-1.so.2 => /lib/libdbus-1.so.2 (0x00511000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x05e3a000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x00668000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x0073e000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x0064e000) libm.so.6 => /lib/libm.so.6 (0x009e7000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x0075c000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x006f4000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00586000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00c37000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00c7a000) libdl.so.2 => /lib/libdl.so.2 (0x00a0e000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00b82000) libc.so.6 => /lib/libc.so.6 (0x008bb000) libcap.so.1 => /lib/libcap.so.1 (0x00648000) libnsl.so.1 => /lib/libnsl.so.1 (0x00c16000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00a36000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00398000) libXext.so.6 => /usr/lib/libXext.so.6 (0x00b35000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0x003d7000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00dfa000) libXi.so.6 => /usr/lib/libXi.so.6 (0x00767000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00642000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00612000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x005da000) /lib/ld-linux.so.2 (0x0089e000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x005e8000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00d7c000) libz.so.1 => /usr/lib/libz.so.1 (0x00a14000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x0027f000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00a31000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00a29000) libexpat.so.0 => /lib/libexpat.so.0 (0x00d59000) From galibert at pobox.com Thu Feb 23 17:28:46 2006 From: galibert at pobox.com (Olivier Galibert) Date: Thu, 23 Feb 2006 18:28:46 +0100 Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) In-Reply-To: <200602231019.28227.lamont@gurulabs.com> References: <43FD0AC0.2090702@redhat.com> <604aa7910602230634l5751103v11690aa4e241fcab@mail.gmail.com> <200602231019.28227.lamont@gurulabs.com> Message-ID: <20060223172846.GB58121@dspnet.fr.eu.org> On Thu, Feb 23, 2006 at 10:19:15AM -0700, Lamont R. Peterson wrote: > By no means is this limited to home users. I would say that the *vast* > majority of corporate admins just turn off SELinux. The story behind how & > why they learned to do that to begin with only vary in details. It's almost > always, "I had problems installing X or doing Y and I found a document on the > Internet that said that SELinux was in the way and didn't work right anyway > and was too complicated and didn't do me any good and that I couldn't learn > enough about it to even understand what was happening, let alone deal with > it, in less than a month and ... well, so I just turn off SELinux and then I > don't have to deal with it." You forgot the alternative, "SELinux does not help at all given our threat model, so it's all cost and no returns". That's the case here. I won't activate SELinux any time soon. OG. From notting at redhat.com Thu Feb 23 17:28:58 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 23 Feb 2006 12:28:58 -0500 Subject: Hotplug: no more fstab entries In-Reply-To: <1140711491.24114.18.camel@daxter.boston.redhat.com> References: <20060222153244.002ea18c@dhcp05.addix.net> <43FC978E.6040006@feuerpokemon.de> <43FCB30D.2020509@unb.ca> <604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com> <20060223103910.2d9874ae@dhcp05.addix.net> <1140698854.3633.1.camel@daxter.boston.redhat.com> <20060223141925.5a085d71@dhcp05.addix.net> <1140701508.3633.9.camel@daxter.boston.redhat.com> <20060223160518.GA13799@devserv.devel.redhat.com> <1140711491.24114.18.camel@daxter.boston.redhat.com> Message-ID: <20060223172858.GC13799@devserv.devel.redhat.com> David Zeuthen (david at fubar.dk) said: > > That's a cheat, though - the introduction is removing functionality from > > the OS. > > Strong disagreement. Prior releases automatically mounted filesystems in all situations; now they are only mounted in the desktop. > You can use gnome-mount and/or mount(1) - they work just fine and > gnome-mount will (at least in the future) do so much more than we could > ever do with the fstab-sync approach. KDE also got some stuff for this > but I don't follow KDE development very closely, sorry. > > You can also use dbus-send in conjunction with hal-find-by-property... > it's not exactly rocket science > > [davidz at daxter ~]$ dbus-send --system --dest=org.freedesktop.Hal --print-reply /org/freedesktop/Hal/devices/volume_uuid_43F1_517C org.freedesktop.Hal.Device.Volume.Unmount array:string: > method return sender=:1.2 -> dest=:1.62 > uint32 0 > [davidz at daxter ~]$ dbus-send --system --dest=org.freedesktop.Hal --print-reply /org/freedesktop/Hal/devices/volume_uuid_43F1_517C org.freedesktop.Hal.Device.Volume.Mount string: string: array:string: > method return sender=:1.2 -> dest=:1.65 > uint32 0 This isn't exactly common use currently, though - I suspect more people understand basic perl line noise than this. :) Is there a way to easily query a d-bus object (from the command line, or even python -c '...') for the supported methods? > > This is all documented in the release notes, right? > > If you think it's necessary.. feel free to add it. I really think we could use one. Bill From jmorris at redhat.com Thu Feb 23 17:33:14 2006 From: jmorris at redhat.com (James Morris) Date: Thu, 23 Feb 2006 12:33:14 -0500 (EST) Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) In-Reply-To: <20060223172846.GB58121@dspnet.fr.eu.org> Message-ID: On Thu, 23 Feb 2006, Olivier Galibert wrote: > You forgot the alternative, "SELinux does not help at all given our > threat model, so it's all cost and no returns". That's the case here. > I won't activate SELinux any time soon. Can I ask what your threat model is? - James -- James Morris From db-fedora at 3di.it Thu Feb 23 17:40:51 2006 From: db-fedora at 3di.it (Davide Bolcioni) Date: Thu, 23 Feb 2006 18:40:51 +0100 Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) In-Reply-To: <200602231019.28227.lamont@gurulabs.com> References: <43FD0AC0.2090702@redhat.com> <604aa7910602230634l5751103v11690aa4e241fcab@mail.gmail.com> <200602231019.28227.lamont@gurulabs.com> Message-ID: <43FDF3A3.3030901@3di.it> Lamont R. Peterson wrote: > By no means is this limited to home users. I would say that the *vast* > majority of corporate admins just turn off SELinux. The story behind how & > why they learned to do that to begin with only vary in details. It's almost > always, "I had problems installing X or doing Y and I found a document on the > Internet that said that SELinux was in the way and didn't work right anyway > and was too complicated and didn't do me any good and that I couldn't learn > enough about it to even understand what was happening, let alone deal with > it, in less than a month and ... well, so I just turn off SELinux and then I > don't have to deal with it." I think we might be aiming at the wrong target, especially in the case of corporate admins. Target application developers, not admins: applications must work without requiring any modification to the system and adapt accordingly. Make modifications invalidate the RHEL support contract: SELinux just helps you to nail down lazy application developers. If the application means more money to the admin than the support contract, he disables it *knowingly* and should the need arise RH support engineers do rpm -Va, notice that something is fishy, and the admin pays per incident or whatever the contract says. If the admin does not like this, next time he'll complain to the application vendor which will get his code, the actual culprit, fixed. Davide Bolcioni -- There is no place like /home. From toshio at tiki-lounge.com Thu Feb 23 17:43:01 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 23 Feb 2006 09:43:01 -0800 Subject: Multiple concurrent versions of Python In-Reply-To: <43FD76EC.70807@balclutha.org> References: <43FD76EC.70807@balclutha.org> Message-ID: <1140716581.3353.37.camel@localhost> On Thu, 2006-02-23 at 19:48 +1100, Alan Milligan wrote: > Toshio Kuratomi wrote: > > > So from the outside looking in, zope-2.9.x is where python-2.4 > > compatibility starts. > > > I've been making contributions to the Zope project for about four years > now, and follow it very closely. If you'd cared to look in the Zope dev > archives, you'd have seen posts from me regarding exactly this issue for > perhaps 8 months now. > If Zope-dev was searchable, I'd have found the information before posting; Google on site:mail.zope.org only pulls out the Zope-announce announcement that Zope-2.8.5 is still not supported with python-2.4. (I've now found out that marc.theaimsgroup keeps archives of zope-dev as well so I'll use that in the future.) Your posting here said that zope-2.8.5 _officially_ supported python-2.4 but all the official announcements I found say unsupported. Now that I know the posts are in zope-dev and from you, here's the thread I found: http://mail.zope.org/pipermail/zope-dev/2005-November/025908.html http://mail.zope.org/pipermail/zope-dev/2005-December/025967.html Which says that zope-2.8.4+ has been security audited for python 2.4 but 2.8.x is not official on python-2.4 and there is no plan to change this. From Jim Fulton: ''' What Andreas is saying is that Python 2.4 still isn't supported for Zope 2.8. This is different from a statement about a security audit. The security audit evaluated and addressed issues arising from a change from Python 2.3 to python 2.4. Zope 2.8.4 reflects this. We still choose not to support Python 2.4 for Zope 2.8 because there hasn't been any sort of test release cycle for Zope 2.8 with Python 2.4. Zope 2.9 will go through such a cycle which will give us at least some consequence. ''' As long as Aurelian has satisfied Andreas Jung with the warnings that support for the FC Zope 2.8.x on python-2.4 is not supported by the Zope Project and that the current release of Plone is not ready for 2.9 then I think we can continue shipping 2.8.x with our system python in the short term. But in the longer term this is a trap because upstream's stance means we risk antagonizing them if we want to go to them for help solving problems. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From lamont at gurulabs.com Thu Feb 23 17:43:15 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Thu, 23 Feb 2006 10:43:15 -0700 Subject: Hotplug: no more fstab entries In-Reply-To: <20060223141925.5a085d71@dhcp05.addix.net> References: <20060222153244.002ea18c@dhcp05.addix.net> <1140698854.3633.1.camel@daxter.boston.redhat.com> <20060223141925.5a085d71@dhcp05.addix.net> Message-ID: <200602231043.57708.lamont@gurulabs.com> On Thursday 23 February 2006 06:19am, Ralf Ertzinger wrote: > Hi. > > On Thu, 23 Feb 2006 07:47:34 -0500, David Zeuthen wrote: > > Don't be silly. You can still use /etc/fstab and/or mount(1). Even > > with the new /disk/disk/by-label etc. symlinks you can construct a > > persistent entry in /etc/fstab. > > Nonetheless, what was wrong with the old behaviour (dropping a directory > in /media for each plugged in device)? I do not even particulary care about > the entries in /etc/fstab, as long as "mount /media/usbdisk" does what it > is supposed to do. > > Can I restore the old behaviour somehow? Sure. Write the udev rule for it, or grab it from an FC4 system (or from the FC4 udev package). Or, if you have some devices that you use frequently, write some custom udev rules. For example, I have this rule for my one main USB Keychain drive (I really need to get a newer, bigger one): # 64MB HP DriveKey BUS="usb", KERNEL="sd*", SYSFS{product}="Drive Key", SYSFS{serial}="0212330F15006816", NAME="key%n" And these two are for a digital video camera I have that records on 3 inch DVD R/RW/RAM discs (video and still photos) or on an SD card (still photos only): BUS="usb", KERNEL="sr*", SYSFS{product}="DVD DIGICAM VDR-M50 Series", NAME="vcamera" BUS="usb", KERNEL="sd?1", SYSFS{product}="DVD DIGICAM VDR-M50 Series", NAME="camera" All of those rules (and a couple of others) are in the /etc/udev/rules.d/10-corsair.rules file (corsair is this notebook's name). For a starter on writing UDEV rules, take a look at Daniel Drake's guide at [ http://www.reactivated.net/udevrules.php ]. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From michael.favia at insitesinc.com Thu Feb 23 17:52:48 2006 From: michael.favia at insitesinc.com (Michael Favia) Date: Thu, 23 Feb 2006 11:52:48 -0600 Subject: eclipse In-Reply-To: <1140712986.24563.15.camel@xpc.home.erwinrol.com> References: <1140712986.24563.15.camel@xpc.home.erwinrol.com> Message-ID: <43FDF670.7060700@insitesinc.com> Erwin Rol wrote: > Hey all, > > I tried to use eclipse for a C++ project but after liek 10 crashes in > the last 30 minutes i kind of gave up. > > My question; is there anybody out there that actually uses eclipse ? And > with uses i mean like working with it 8 hours a day without a crash ever > 5 minutes. I tried using andrews eclipse packages at first because dont like the idea of a noncentrally managed update stack. But the original packaging problems with installing only the eclipse platform (eg non SDK), user based extension directories, and the trouble with the speed and functionality of those installed extensions left a little to be desired. As a result i have been running eclipse platform+CDT+phpeclipse+subclipse ontop of a Sun Java stack (for speed alone) for the last few months. I havent toyed around with the updates andrews made in the past few months. i seem to remember seeing changelogs in the rawhide update messages that resolved most of my issues. Will install this afternoon and report back with troubles if any. -mf -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com From galibert at pobox.com Thu Feb 23 17:59:43 2006 From: galibert at pobox.com (Olivier Galibert) Date: Thu, 23 Feb 2006 18:59:43 +0100 Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) In-Reply-To: References: <20060223172846.GB58121@dspnet.fr.eu.org> Message-ID: <20060223175943.GA68343@dspnet.fr.eu.org> On Thu, Feb 23, 2006 at 12:33:14PM -0500, James Morris wrote: > On Thu, 23 Feb 2006, Olivier Galibert wrote: > > > You forgot the alternative, "SELinux does not help at all given our > > threat model, so it's all cost and no returns". That's the case here. > > I won't activate SELinux any time soon. > > Can I ask what your threat model is? We're a governmental research lab somewhere, with students and visitors coming around and even classes in the conference rooms on a regular basis. The computers are behind a reasonable, bidirectional firewall. All disks are nfs-exported everywhere so that anyone can work no matter what computer they're on. You can always find some ips that are in the access lists but for which the associated computer is offline at the time, especially since the list is accessed through NIS. Also rlogind is active on most of the computers. Next to that, the web servers, ftp servers, etc are reasonably competently administred, with rampant paranoia w.r.t all scripts in there and this kind of stuff. We don't have wifi at that point. The biggest data loss we've had in some years is when someone stole a server computer, disks and all. So our real threat is physical access, either stealing computers/disks or plugging into the network. The technical answer to that is paranoid encryption everywhere, which won't happen because the cost is way higher than the risk. SELinux doesn't enter the picture at any point. Remote control of a windows desktop box would be the secondary threat if it wasn't for the bidirectional firewall. The unix systems are far behind. OG. From jspaleta at gmail.com Thu Feb 23 18:08:34 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 23 Feb 2006 13:08:34 -0500 Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) In-Reply-To: References: <20060223172846.GB58121@dspnet.fr.eu.org> Message-ID: <604aa7910602231008g5f188097t26eae60d82a33598@mail.gmail.com> On 2/23/06, James Morris wrote: > Can I ask what your threat model is? Primary threat: bear attacks Secondary threat: moose attacks -jef From tadams-lists at myrealbox.com Thu Feb 23 18:11:08 2006 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Thu, 23 Feb 2006 11:11:08 -0700 Subject: Ralink rt2500, can't load module In-Reply-To: <43FDD1CE.5000208@insitesinc.com> References: <43FB7DC9.8060307@vip.hr> <1140559789.3082.37.camel@laptopd505.fenrus.org> <1140591640.2284.13.camel@aurora.localdomain> <43FCDA81.80703@vip.hr> <43FCFBE3.9030801@insitesinc.com> <43FD62ED.7070701@vip.hr> <43FDD1CE.5000208@insitesinc.com> Message-ID: <1140718268.2305.21.camel@aurora.localdomain> The below patch is NOT the correct solution. The solutions is to fix up the calls. The new format for module_param is module_param(NAME, TYPE, PERMISSION); So, the NAME is obvious, it stays the same. The TYPE is one of (byte, short, ushort, int, uint, long, ulong, charp, bool or invbool). I just now found this http://lwn.net/Articles/22197/ . It answers all the questions of how to do the fix. I wish I would have found this a month ago when I was making the driver work. It would have answered my question in minutes instead of the two hours it took me to track down. Trever On Thu, 2006-02-23 at 09:16 -0600, Michael Favia wrote: > Index: rtmp_main.c > =================================================================== > RCS file: /cvsroot/rt2400/source/rt2500/Module/rtmp_main.c,v > retrieving revision 1.64 > diff -u -r1.64 rtmp_main.c > --- rtmp_main.c 9 Feb 2006 23:42:10 -0000 1.64 > +++ rtmp_main.c 22 Feb 2006 23:33:41 -0000 > @@ -58,8 +58,8 @@ > MODULE_PARM_DESC(debug, "Enable level: accepted values: 1 to switch debug on, 0 to switch debug off."); > > static char *ifname = NULL ; > -MODULE_PARM(ifname, "s"); > -MODULE_PARM_DESC(ifname, "Network device name (default ra%d)"); > +//MODULE_PARM(ifname, "s"); > +//MODULE_PARM_DESC(ifname, "Network device name (default ra%d)"); > > // Following information will be show when you run 'modinfo' > MODULE_AUTHOR("http://rt2x00.serialmonkey.com"); -- "Stop searching forever. Happiness is just next to you." -- Unknown From tadams-lists at myrealbox.com Thu Feb 23 18:12:49 2006 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Thu, 23 Feb 2006 11:12:49 -0700 Subject: Ralink rt2500, can't load module In-Reply-To: <51067.193.52.109.12.1140709412.squirrel@webmail.univ-nantes.fr> References: <43FB7DC9.8060307@vip.hr> <1140559789.3082.37.camel@laptopd505.fenrus.org> <1140591640.2284.13.camel@aurora.localdomain> <1140644675.3119.4.camel@bureau.maison> <1140681626.4681.13.camel@aurora.localdomain> <51067.193.52.109.12.1140709412.squirrel@webmail.univ-nantes.fr> Message-ID: <1140718370.2305.24.camel@aurora.localdomain> On Thu, 2006-02-23 at 16:43 +0100, Eric TANGUY wrote: > I found it in the forum : > http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=675&start=0&postdays=0&postorder=asc&highlight= > But it seems to not be relevant to this problem : > "That topic is about the rt2x00 driver not the legacy driver. > And the patch was not for rt2x00 but for the ieee80211 stack." > > Eric At that point only the ieee80211 stack had the problems. The topic was some one else's. I just followed up and found some of the answers my self. The problem still seems to be the same, just in a different part of the code. See my last message in this thread. BTW, ANY 2.6 kernel will use this stuff. So, if you don't mind only hitting 2.6 and up, you can just fix it the way I describe, no ifdefs, and all will be good. Trever -- "Love is friendship set on fire." -- French Proverb From tiemann at redhat.com Thu Feb 23 18:13:03 2006 From: tiemann at redhat.com (Michael Tiemann) Date: Thu, 23 Feb 2006 13:13:03 -0500 Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) In-Reply-To: <604aa7910602231008g5f188097t26eae60d82a33598@mail.gmail.com> References: <20060223172846.GB58121@dspnet.fr.eu.org> <604aa7910602231008g5f188097t26eae60d82a33598@mail.gmail.com> Message-ID: <1140718384.3722.28.camel@localhost.localdomain> On Thu, 2006-02-23 at 13:08 -0500, Jeff Spaleta wrote: > On 2/23/06, James Morris wrote: > > Can I ask what your threat model is? > > Primary threat: bear attacks > Secondary threat: moose attacks What if somebody approaches you holding a banana? M From db-fedora at 3di.it Thu Feb 23 18:16:27 2006 From: db-fedora at 3di.it (Davide Bolcioni) Date: Thu, 23 Feb 2006 19:16:27 +0100 Subject: Funny .so situation under FC5 test 3 Message-ID: <43FDFBFB.5010102@3di.it> Greetings, I am testing a binary-only application under FC5 test 3 and find the following situation: - ldd on the main executable shows, among others, libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40050000) - ldd on a .so loaded by the main executable shows, among others, libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x4014c000) The application seems to work but the above situation is new to me, why did this happen ? Is this a problem ? Thank you for your consideration, Davide Bolcioni From gnomeuser at gmail.com Thu Feb 23 18:32:22 2006 From: gnomeuser at gmail.com (David Nielsen) Date: Thu, 23 Feb 2006 19:32:22 +0100 Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) In-Reply-To: <1140718384.3722.28.camel@localhost.localdomain> References: <20060223172846.GB58121@dspnet.fr.eu.org> <604aa7910602231008g5f188097t26eae60d82a33598@mail.gmail.com> <1140718384.3722.28.camel@localhost.localdomain> Message-ID: <1140719543.2152.0.camel@price.stavtrup-st.dk> tor, 23 02 2006 kl. 13:13 -0500, skrev Michael Tiemann: > On Thu, 2006-02-23 at 13:08 -0500, Jeff Spaleta wrote: > > On 2/23/06, James Morris wrote: > > > Can I ask what your threat model is? > > > > Primary threat: bear attacks > > Secondary threat: moose attacks > > What if somebody approaches you holding a banana? You release the Begal tiger of course -- Obligatory shameless blog plug - the GNOME commentary located at: www.lovesunix.net/blog From galibert at pobox.com Thu Feb 23 18:36:23 2006 From: galibert at pobox.com (Olivier Galibert) Date: Thu, 23 Feb 2006 19:36:23 +0100 Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) In-Reply-To: <604aa7910602231008g5f188097t26eae60d82a33598@mail.gmail.com> References: <20060223172846.GB58121@dspnet.fr.eu.org> <604aa7910602231008g5f188097t26eae60d82a33598@mail.gmail.com> Message-ID: <20060223183623.GB68343@dspnet.fr.eu.org> On Thu, Feb 23, 2006 at 01:08:34PM -0500, Jeff Spaleta wrote: > On 2/23/06, James Morris wrote: > > Can I ask what your threat model is? > > Primary threat: bear attacks > Secondary threat: moose attacks Thankfully I don't have a sister. OG. From fedora at leemhuis.info Thu Feb 23 17:53:11 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 23 Feb 2006 18:53:11 +0100 Subject: Unite Non-free repos (Was: Re: Non-free Extras?) In-Reply-To: References: <43FBA1CD.4020908@gmail.com> <1140565924.31940.17.camel@T7.Linux> <43FC1F67.7080607@argo.co.il> <20060222120630.GD20029@devserv.devel.redhat.com> <43FC5A1B.4070106@cornell.edu> <43FCC1D2.4020206@gmail.com> <1140641962.4192.102.camel@localhost.localdomain> Message-ID: <1140717191.2140.17.camel@localhost.localdomain> Am Donnerstag, den 23.02.2006, 18:23 +0100 schrieb Rudolf Kastl: > 2006/2/22, Thorsten Leemhuis : > > Am Mittwoch, den 22.02.2006, 14:56 -0500 schrieb Eric Mesa: > > well id be happy if just planetccrma would be slowly merged into > extras... the main blocker seems to be the realtime kernel module as > far as i can see. Well, we had a discussion about "kernels in Fedora Extras" on this list some months ago. I don't think that we should provide them there. But that's debatable. And even if we agree not to ship them: planetccrma could still ship the kernels and we could merge everything else into extras if possible. > actually from the other repos only a few packages are missing that > could be contributed to extras and youd be nearly there. besides some > kernel modules atrpms provides e.g. Well, the confusion for the user remains as long as freshrpms, atrpms rpmforge and livna exist in their current state. I've seen multiple users that didn't know that repo mixing can result in "interesting results". Most users hit those sooner or later and ran away screaming to Ubuntu or Suse. CU thl -- Thorsten Leemhuis From arjan at fenrus.demon.nl Thu Feb 23 18:43:33 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 23 Feb 2006 19:43:33 +0100 Subject: Funny .so situation under FC5 test 3 In-Reply-To: <43FDFBFB.5010102@3di.it> References: <43FDFBFB.5010102@3di.it> Message-ID: <1140720214.4672.89.camel@laptopd505.fenrus.org> On Thu, 2006-02-23 at 19:16 +0100, Davide Bolcioni wrote: > Greetings, > I am testing a binary-only application under FC5 test 3 and find the > following situation: > > - ldd on the main executable shows, among others, > > libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40050000) > > - ldd on a .so loaded by the main executable shows, among others, > > libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 > (0x4014c000) > > The application seems to work but the above situation is new to me, > why did this happen ? Is this a problem ? it's not uncommon for plugins to have this. It sucks, you eat memory like it's no tomorrow, but it works. From jreiser at BitWagon.com Thu Feb 23 18:53:21 2006 From: jreiser at BitWagon.com (John Reiser) Date: Thu, 23 Feb 2006 10:53:21 -0800 Subject: Funny .so situation under FC5 test 3 In-Reply-To: <43FDFBFB.5010102@3di.it> References: <43FDFBFB.5010102@3di.it> Message-ID: <43FE04A1.7080402@BitWagon.com> > - ldd on the main executable shows, among others, > > libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40050000) > > - ldd on a .so loaded by the main executable shows, among others, > > libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 > (0x4014c000) > why did this happen ? The ABI between libstdc++ and code generated by g++ has not been stable. -- From michael.favia at insitesinc.com Thu Feb 23 19:17:14 2006 From: michael.favia at insitesinc.com (Michael Favia) Date: Thu, 23 Feb 2006 13:17:14 -0600 Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) In-Reply-To: <1140718384.3722.28.camel@localhost.localdomain> References: <20060223172846.GB58121@dspnet.fr.eu.org> <604aa7910602231008g5f188097t26eae60d82a33598@mail.gmail.com> <1140718384.3722.28.camel@localhost.localdomain> Message-ID: <43FE0A3A.40205@insitesinc.com> Michael Tiemann wrote: > On Thu, 2006-02-23 at 13:08 -0500, Jeff Spaleta wrote: >> On 2/23/06, James Morris wrote: >>> Can I ask what your threat model is? >> Primary threat: bear attacks >> Secondary threat: moose attacks > > What if somebody approaches you holding a banana? Tertiary threat: gorilla attacks. -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com From smooge at gmail.com Thu Feb 23 19:32:37 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Thu, 23 Feb 2006 12:32:37 -0700 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <43FD78EC.4080104@3di.it> References: <43FD0AC0.2090702@redhat.com> <43FD78EC.4080104@3di.it> Message-ID: <80d7e4090602231132r2d1267b6i8a62e812b2739a12@mail.gmail.com> On 2/23/06, Davide Bolcioni wrote: > Mike A. Harris wrote: > > > Both ATI and Nvidia's proprietary video driver installation utilities > > replace the Red Hat supplied libGL library with their own libGL. > > Could SELinux be used to prevent this and, more generally, disallow > replacement of rpm-controlled files even by the root user ? > > Davide Bolcioni > Quite possibly. But the first BAD FAQ will be on the mailling lists: How do I get my nvidia card to perform decently? Download the tar balls from nvidia, and reboot your system with SELINUX=0. -- Stephen J Smoogen. CSIRT/Linux System Administrator From fedora at camperquake.de Thu Feb 23 19:46:34 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 23 Feb 2006 20:46:34 +0100 Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) In-Reply-To: <200602231019.28227.lamont@gurulabs.com> References: <43FD0AC0.2090702@redhat.com> <604aa7910602230634l5751103v11690aa4e241fcab@mail.gmail.com> <200602231019.28227.lamont@gurulabs.com> Message-ID: <20060223204634.21654c4f@dhcp05.addix.net> Hi. On Thu, 23 Feb 2006 10:19:15 -0700, Lamont R. Peterson wrote: > details. It's almost always, "I had problems installing X or doing Y > and I found a document on the Internet that said that SELinux was in > the way and didn't work right anyway and was too complicated and > didn't do me any good and that I couldn't learn enough about it to > even understand what was happening, let alone deal with it, in less > than a month and ... well, so I just turn off SELinux and then I > don't have to deal with it." I am in exactly that situation right now. I am migrating a whole bunch of machines over to a selinux-capable system, but I turn it off, mainly because I do not even remotely know enough about how it works and how one uses it. It sucks. Majorly. Is there a decent book available on understanding and managing selinux (covering what is available in RHEL4)? I am quite fond of dead tree versions for learning about a topic, and printing out PDFs is unsatisfying. From david at fubar.dk Thu Feb 23 20:03:25 2006 From: david at fubar.dk (David Zeuthen) Date: Thu, 23 Feb 2006 15:03:25 -0500 Subject: Hotplug: no more fstab entries In-Reply-To: <20060223172858.GC13799@devserv.devel.redhat.com> References: <20060222153244.002ea18c@dhcp05.addix.net> <43FC978E.6040006@feuerpokemon.de> <43FCB30D.2020509@unb.ca> <604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com> <20060223103910.2d9874ae@dhcp05.addix.net> <1140698854.3633.1.camel@daxter.boston.redhat.com> <20060223141925.5a085d71@dhcp05.addix.net> <1140701508.3633.9.camel@daxter.boston.redhat.com> <20060223160518.GA13799@devserv.devel.redhat.com> <1140711491.24114.18.camel@daxter.boston.redhat.com> <20060223172858.GC13799@devserv.devel.redhat.com> Message-ID: <1140725006.13317.7.camel@daxter.boston.redhat.com> On Thu, 2006-02-23 at 12:28 -0500, Bill Nottingham wrote: > David Zeuthen (david at fubar.dk) said: > > > That's a cheat, though - the introduction is removing functionality from > > > the OS. > > > > Strong disagreement. > > Prior releases automatically mounted filesystems in all situations; No, we just provided 1) an /etc/fstab entry; and 2) created/maintained a directory in /media. > now they are only mounted in the desktop. There are no big changes for desktop users. > > [davidz at daxter ~]$ dbus-send --system --dest=org.freedesktop.Hal --print-reply /org/freedesktop/Hal/devices/volume_uuid_43F1_517C org.freedesktop.Hal.Device.Volume.Unmount array:string: > > method return sender=:1.2 -> dest=:1.62 > > uint32 0 > > [davidz at daxter ~]$ dbus-send --system --dest=org.freedesktop.Hal --print-reply /org/freedesktop/Hal/devices/volume_uuid_43F1_517C org.freedesktop.Hal.Device.Volume.Mount string: string: array:string: > > method return sender=:1.2 -> dest=:1.65 > > uint32 0 > > This isn't exactly common use currently, though - I suspect > more people understand basic perl line noise than this. :) > > Is there a way to easily query a d-bus object (from the command > line, or even python -c '...') for the supported methods? No, not yet, sorry. HAL was written before the introspection format in D-BUS settled... so HAL currently don't support introspection... I want to add this when D-BUS goes 1.0 though... > > > This is all documented in the release notes, right? > > > > If you think it's necessary.. feel free to add it. > > I really think we could use one. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182639 David From davej at redhat.com Thu Feb 23 20:17:26 2006 From: davej at redhat.com (Dave Jones) Date: Thu, 23 Feb 2006 15:17:26 -0500 Subject: Where did all my memory go? In-Reply-To: <20060223143555.GA36205@dspnet.fr.eu.org> References: <43FDC0D5.1050901@cornell.edu> <20060223143555.GA36205@dspnet.fr.eu.org> Message-ID: <20060223201726.GC6213@redhat.com> On Thu, Feb 23, 2006 at 03:35:55PM +0100, Olivier Galibert wrote: > On Thu, Feb 23, 2006 at 09:04:05AM -0500, Ivan Gyurdiev wrote: > [...rpm -Va...] > > What's using up all the memory? > > File caching, obviously. Current VM is not that good at handling > streaming a bunch of files through an application. Well, it > agressively caches the file for the application itself, too bad it > doesn't care about them anymore after one load, and meanwhile swaps > out whatever is on the computer too. His looks more like a leak. 12535365 size-32 slabs is definitly an abnormal situation. Dave From ihok at hotmail.com Thu Feb 23 20:21:00 2006 From: ihok at hotmail.com (Jack Tanner) Date: Thu, 23 Feb 2006 15:21:00 -0500 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <43FD0AC0.2090702@redhat.com> References: <43FD0AC0.2090702@redhat.com> Message-ID: <43FE192C.9000805@hotmail.com> This sounds like an incredibly useful thing to have in the release notes for FC5, perhaps in abbreviated form. CC'ing relnotes@ as per instructions at http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Process Mike A. Harris wrote: > There have been a number of bugs reported in Red Hat bugzilla against > X which have recently been tracked down to 3rd party video drivers being > the culprit behind the problem the user was experienced. In many of the > cases however, it wasn't obvious that the 3rd party drivers were at > fault because the user was actually using the Red Hat supplied drivers, > and not using the 3rd party driver that they had previously installed. > > Since I've wasted at least 6-8 hours in the last month diagnosing issues > of this nature which have later turned out to be caused by proprietary > drivers having been "installed" on the system, wether they were actually > being *used* or not, I thought I should write a short useful > informational email on the topic to the lists to try and inform people > of some pitfalls you may encounter if you even _install_ 3rd party > video drivers. > > Both ATI and Nvidia, and perhaps even other 3rd party drivers out there > come in some form of tarball or equivalent form from the particular > vendor. Most users seem to favour the hardware vendor supplied drivers > directly, rather than using more sanely packaged 3rd party packages that > contain the same drivers. This is very unfortunate, because installing > these 3rd party tarball driver installations is very harmful to your > clean OS installation. > > Both ATI and Nvidia's proprietary video driver installation utilities > replace the Red Hat supplied libGL library with their own libGL. > Nvidia's driver installs a replacement libglx.a X server module, > removing the Red Hat supplied X.Org module in the process. ATI's > driver may or may not replace libglx.a with it's own, I haven't checked > (but if someone could confirm that, I'd appreciate knowing for certain). > > Once you have either of these drivers installed on your system, you > can no longer use DRI with any video card. So if you install the > ATI fglrx driver, while you should still be able in theory at least > to use the Red Hat supplied radeon driver, you may no longer be able > to use DRI with the radeon driver, because ATI's driver has blown away > critical files that come with the OS that are needed for proper > operation. > > If you install Nvidia's driver, and later decide to install an ATI > card, and still have Nvidia's driver installed, bang - you will not > be able to get Red Hat supplied DRI 3D acceleration to work. You must > remove Nvidia's driver completely from your hard disk, and completely > reinstall all of the xorg-x11 and mesa packages, and ensure they are > all intact by using: > > rpm -Va > > Another problem being reported by a few people, is they are unable to > get DRI to work because mesa libGL is looking for the DRI drivers in > the wrong directory. The claim is that mesa is looking for the DRI > drivers in /usr/X11R6/lib/modules. > > On a fresh OS install however, my findings are that mesa's libGL very > much is not looking in /usr/X11R6 for it's modules. It is looking in > the proper location of /usr/lib/dri for the modules. Why then is it > looking in the wrong place on some systems? > > Answer: Because of fglrx having been installed. If you have had a > previous OS release installed, and have installed ATI's fglrx driver > from tarball, it has removed the OS supplied libGL et al and made > backup copies of them aparently. Now you do an OS upgrade which works > properly and installs everything in the right place. Then you uninstall > ATI's fglrx with whatever script or whatever they supply, and now you > try to run X, and get no DRI! > > Well, since you don't have fglrx installed at all, it must be our > OS at fault right! Wrong. the uninstall script has put the OLD > libGL it backed up (from FC4 or whatever) back in the system, > overwriting the new FC5 supplied libGL in the process, and since > ATI's fglrx driver is DRI based as well, it looks for the DRI > modules in the wrong place now. > > Conclusions: > If you are going to use any 3rd party proprietary drivers, please do > yourself and everyone else a huge favour, and at least get your > drivers from reputable 3rd party rpm package repositories such as > livna.org which packages both the nvidia and ati proprietary drivers > in rpm packages which install the drivers sanely without overwriting > Red Hat/Fedora supplied files. These 3rd party packages install > the files in alternative locations, and configure the X server et al. > appropriately so that everything works. Since they do not blow > away OS supplied files, you can use the OS supplied drivers still > by reconfiguring xorg.conf. Also, if you decide to uninstall the > 3rd party drivers via rpm, they just go away and cause no further > harm to the system. So PLEASE USE THIRD PARTY RPM PACKAGES if you > _must_ use 3rd party drivers. It helps create world peace. > > If you choose to install ATI or Nvidia tarball/whatever drivers > directly from ATI/Nvidia (or any other vendor for that matter), your > system is 100% completely and totally unsupported. Even if you are > using _our_ drivers, your 3rd party driver installation may have > blown away our libGL, our libglx.a or any other files that have been > supplied by our OS. As such, your system is not supported. > > For those who encounter a bug of any kind whatsoever while using > 3rd party video drivers, completely remove the 3rd party drivers > from your system, and then perform a full "yum update" to ensure > you have the latest Fedora Core supplied X packages installed. After > doing this, do an "rpm -Va" of your whole system, in particular the > xorg-x11-*, mesa-* and lib* packages. If there are any discrepancies > found in any of the Fedora supplied packages, in particular in libGL, > or the X server packages, remove them and reinstall them and reverify > that the files installed on your system are the ones shipped by > Fedora. > > If you are able to reproduce the problem you are having after having > performed these steps, and having ensured that you are neither using > 3rd party drivers, nor even have them installed, then feel free to > file a bug report in bugzilla. > > By doing this small amount of pre-diagnosis of your own system if > you are using 3rd party drivers, you will save yourself a lot of > headaches, and will save other people, including developers such > as myself from wasting endless hours trying to diagnose problems > which turn out to be bogus. Hours which could have been spent > fixing legitimate bugs that are present in bugzilla. > > As an additional note - if anyone is using proprietary drivers and > has any problems which they believe might actually be a bug in > Xorg and not in their proprietary driver - file such bugs directly > in X.Org bugzilla. X.Org has an nVidia (closed) component specifically > for the proprietary driver, and Nvidia engineers get those bugs and > will investigate them over time. > > Anyhow, I hope this helps people understand at least some of the > problems that can occur when you opt to using 3rd party drivers, > present some alternatives, and to help people diagnose their own > problems which might be caused by having installed 3rd party > drivers. > > Thanks for reading. > TTYL > > > P.S. Feel free to forward this email on to any other lists or > people whom you think might benefit from it. Also, if anyone thinks > this information would be useful to have on the Fedora Wiki or > somewhere else, feel free to copy my email into a wiki page, or > paraphrase, etc. > > > From ivg2 at cornell.edu Thu Feb 23 20:23:52 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 23 Feb 2006 15:23:52 -0500 Subject: Where did all my memory go? In-Reply-To: <20060223201726.GC6213@redhat.com> References: <43FDC0D5.1050901@cornell.edu> <20060223143555.GA36205@dspnet.fr.eu.org> <20060223201726.GC6213@redhat.com> Message-ID: <43FE19D8.20801@cornell.edu> > His looks more like a leak. > 12535365 size-32 slabs is definitly an abnormal situation. > Yes, it's definitely reproducible too, seems to happen every time I boot, which is rather odd, because I've been running with the same kernel and drivers for a few days now. Something must have broken it in recent upgrades. I am suspicious of mono... but otoh I tried killing almost every app without recovering the memory, so doesn't that indicate a kernel problem? I will do testing without the nvidia driver, and also with a stock kernel (and without mono) to uncover the problem. Not sure what this means exactly, but oprofile says: Counted MEM_PAGE_ACCESS events (Memory controller page access) with a unit mask of 0x07 (multiple flags) count 30000 MEM_PAGE_ACCES...| samples| %| ------------------ 45007 46.9326 mono MEM_PAGE_ACCES...| samples| %| ------------------ 33829 75.1639 mono 3217 7.1478 anon (tgid:3087 range:0x40caa000-0x40d1a000) 3139 6.9745 anon (tgid:3087 range:0x40225000-0x40265000) 1843 4.0949 anon (tgid:3087 range:0x40014000-0x40024000) 952 2.1152 anon (tgid:3087 range:0x40878000-0x408a8000) 608 1.3509 anon (tgid:2815 range:0x40225000-0x40275000) 375 0.8332 anon (tgid:3087 range:0x40f1b000-0x40f8b000) 293 0.6510 anon (tgid:3087 range:0x40466000-0x40476000) 277 0.6155 anon (tgid:2815 range:0x40476000-0x40526000) 153 0.3399 anon (tgid:2815 range:0x42d93000-0x42e13000) 113 0.2511 anon (tgid:3087 range:0x40f1b000-0x40f7b000) 94 0.2089 anon (tgid:2815 range:0x40014000-0x40024000) 46 0.1022 anon (tgid:3087 range:0x40f1b000-0x40f6b000) 36 0.0800 anon (tgid:2815 range:0x41f7c000-0x41f8c000) 21 0.0467 anon (tgid:2815 range:0x40b29000-0x40b39000) 10 0.0222 anon (tgid:2815 range:0x42d93000-0x42df3000) 1 0.0022 anon (tgid:3087 range:0x40000000-0x40010000) 23274 24.2698 vmlinux 13175 13.7387 libc-2.3.90.so 1827 1.9052 libglib-2.0.so.0.902.4 1367 1.4255 libfb.so 1332 1.3890 nvidia_drv.so 1180 1.2305 nvidia 1128 1.1763 libpthread-2.3.90.so 908 0.9468 ext3 849 0.8853 libsqlite3.so.0.8.6 From poelstra at redhat.com Thu Feb 23 20:36:07 2006 From: poelstra at redhat.com (John Poelstra) Date: Thu, 23 Feb 2006 15:36:07 -0500 Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) In-Reply-To: <20060223204634.21654c4f@dhcp05.addix.net> References: <43FD0AC0.2090702@redhat.com> <604aa7910602230634l5751103v11690aa4e241fcab@mail.gmail.com> <200602231019.28227.lamont@gurulabs.com> <20060223204634.21654c4f@dhcp05.addix.net> Message-ID: <43FE1CB7.9080506@redhat.com> Ralf Ertzinger wrote: > Is there a decent book available on understanding and managing > selinux (covering what is available in RHEL4)? I am quite fond > of dead tree versions for learning about a topic, and printing > out PDFs is unsatisfying. > http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ http://www.amazon.com/gp/search/ref=br_ss_hs/103-0884455-3434219?search-alias=aps&keywords=selinux From david at fubar.dk Thu Feb 23 21:01:28 2006 From: david at fubar.dk (David Zeuthen) Date: Thu, 23 Feb 2006 16:01:28 -0500 Subject: Hotplug: no more fstab entries In-Reply-To: <604aa7910602230840t3805e76cq4e30630883b90c60@mail.gmail.com> References: <20060222153244.002ea18c@dhcp05.addix.net> <43FC978E.6040006@feuerpokemon.de> <43FCB30D.2020509@unb.ca> <604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com> <20060223103910.2d9874ae@dhcp05.addix.net> <1140698854.3633.1.camel@daxter.boston.redhat.com> <20060223141925.5a085d71@dhcp05.addix.net> <1140701508.3633.9.camel@daxter.boston.redhat.com> <20060223160518.GA13799@devserv.devel.redhat.com> <1140711491.24114.18.camel@daxter.boston.redhat.com> <604aa7910602230840t3805e76cq4e30630883b90c60@mail.gmail.com> Message-ID: <1140728488.13317.23.camel@daxter.boston.redhat.com> Hi Jef, On Thu, 2006-02-23 at 11:40 -0500, Jeff Spaleta wrote: > If I had a better personal understanding of the capabilities of the > dbus commandline tools like dbus-send that would help. Are there > existing examples of dbus-send usage that do useful work in the wild? This document is out of date http://webcvs.freedesktop.org/*checkout*/hal/hal/doc/spec/hal-spec.html but it is where stuff like this will end of for HAL... but we're pre-1.0 so we're working more on code than documentation. We take patches though :-). Send them to http://lists.freedesktop.org/mailman/listinfo/hal We can also answer specific questions about what parameters the Mount() method takes. And I'm normally a lot more reasonable on that list than here :-).... The best advice I can give you right now... is to read the gnome mount source... here http://cvs.gnome.org/viewcvs/*checkout*/gnome-mount/src/gnome-mount.c it will show you what the parameters are... and what exceptions you need to catch.. Hope this helps... Btw /etc/pm/hooks/00NetworkManager is one example of using dbus-send. > I honestly do not grok dbus communication well enough to be able to > parse the example you give usefully from a "get crap done with a shell > script" sysadmin point of view. And the errors spawned the what I > assume to be non-functional example in the dbus-send on the fc4 > manpage leaves my mouth agape and my eyes glassy. > > If you know of something better than > http://dbus.freedesktop.org/doc/dbus-tutorial.html > to help sysadmins learn enough about dbus to use dbus-send effectively > please let me know. Especially any existing generally useful scripts > that exist to do useful work. >From another mail: > Actually since we are talking about scripting dbus actions with the > cmdline tools... how do i get access to dbus's introspection ability > via the cmdline tools so that as a sysadmin I can explore the object > path and valid messages? There is not really an easy way to do this yet. But someday we'll have nice introspection and a generic browser UI for these. David From michael.favia at insitesinc.com Thu Feb 23 21:01:12 2006 From: michael.favia at insitesinc.com (Michael Favia) Date: Thu, 23 Feb 2006 15:01:12 -0600 Subject: eclipse In-Reply-To: <43FDF670.7060700@insitesinc.com> References: <1140712986.24563.15.camel@xpc.home.erwinrol.com> <43FDF670.7060700@insitesinc.com> Message-ID: <43FE2298.9030703@insitesinc.com> Michael Favia wrote: > Will install this afternoon and report back with troubles if > any. -mf Had a chance to install this afternoon. Is this really still necessary (please see dependency resolution report from yum on bottom of msg)? Some of those make sense to me but tomcat? I seem to remember something about this issue before but don't remember what in particular it was. Other than that it seems to run clean and work well. Was able to use my existing workspace and add my extension location without issue at all. I'm going to pound on it in the cdt and phpeclipse arena a little more but subclipse and the basics all seem to be functional if not a tad bit sluggish (i have no metrics to back that up). Is there a policy for those extensions that make it into the repo and those that don't? Or a general fedora policy on how to handle extensible applications (gstreamer, firefox, thunderbird, eclipse)? Because their support seems to differ across applications. Maintaining every extension seems like a waste of developer resources and asking each user on a system to install the same extension seems redundant and tedious. Regardless thanks for all the good work andrew et al. and ill report any new issues to bugzilla. -mf DEPS: ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: eclipse-platform i386 1:3.1.2-1jpp_7fc development 53 M Installing for dependencies: ant-apache-bsf i386 1.6.5-1jpp_6fc development 44 k ant-javamail i386 1.6.5-1jpp_6fc development 34 k eclipse-rcp i386 1:3.1.2-1jpp_7fc development 46 k geronimo-specs i386 1.0-0.M2.2jpp_7fc development 227 k geronimo-specs-compat i386 1.0-0.M2.2jpp_7fc development 4.9 k jakarta-commons-fileupload noarch 1:1.0-3jpp_4fc development 24 k java-1.4.2-gcj-compat-javadoc i386 1.4.2.0-40jpp_80rh development 21 M lucene i386 1.4.3-1jpp_11fc development 660 k lucene-demo i386 1.4.3-1jpp_11fc development 104 k tomcat5 i386 5.0.30-8jpp_11fc development 3.6 M tomcat5-jasper i386 5.0.30-8jpp_11fc development 878 k Transaction Summary ============================================================================= Install 12 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 80 M -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com From jdesbonnet at gmail.com Thu Feb 23 21:22:11 2006 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Thu, 23 Feb 2006 21:22:11 +0000 Subject: Virtual machine software for Fedora testing? Message-ID: <1cef3e950602231322u3c43f267k1a08290cf8755c47@mail.gmail.com> Is there any free virtual machine software (like VMWare) that can be used for testing Fedora installation? I want to test the latest version of my delta rpm system for keeping Fedora boxes updated over low bandwidth links. But I don't have a spare machine... Thanks, Joe. From fedora-devel-list at cygnusx-1.org Thu Feb 23 21:26:58 2006 From: fedora-devel-list at cygnusx-1.org (Nathan Grennan) Date: Thu, 23 Feb 2006 13:26:58 -0800 Subject: Virtual machine software for Fedora testing? In-Reply-To: <1cef3e950602231322u3c43f267k1a08290cf8755c47@mail.gmail.com> References: <1cef3e950602231322u3c43f267k1a08290cf8755c47@mail.gmail.com> Message-ID: <43FE28A2.20906@cygnusx-1.org> Joe Desbonnet wrote: > Is there any free virtual machine software (like VMWare) that can be > used for testing Fedora installation? > > I want to test the latest version of my delta rpm system for keeping > Fedora boxes updated over low bandwidth links. But I don't have a > spare machine... > qemu: http://dries.studentenweb.org/rpm/packages/qemu/info.html http://fabrice.bellard.free.fr/qemu/ Xen: Which is in FC4 and will be in FC5 VMware GSX server: Now free, but the new free version is still in beta last I heard. From ivazquez at ivazquez.net Thu Feb 23 21:37:06 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 23 Feb 2006 16:37:06 -0500 Subject: Virtual machine software for Fedora testing? In-Reply-To: <43FE28A2.20906@cygnusx-1.org> References: <1cef3e950602231322u3c43f267k1a08290cf8755c47@mail.gmail.com> <43FE28A2.20906@cygnusx-1.org> Message-ID: <1140730626.4203.4.camel@ignacio.lan> On Thu, 2006-02-23 at 13:26 -0800, Nathan Grennan wrote: > VMware GSX server: > Now free, but the new free version is still in beta last I heard. No, VMware Server is gratis. VMware GSX is a separate product. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-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 Thu Feb 23 21:42:11 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 23 Feb 2006 16:42:11 -0500 Subject: Hotplug: no more fstab entries In-Reply-To: <1140728488.13317.23.camel@daxter.boston.redhat.com> References: <20060222153244.002ea18c@dhcp05.addix.net> <604aa7910602221110i566174cq56d9f687ca7e048c@mail.gmail.com> <20060223103910.2d9874ae@dhcp05.addix.net> <1140698854.3633.1.camel@daxter.boston.redhat.com> <20060223141925.5a085d71@dhcp05.addix.net> <1140701508.3633.9.camel@daxter.boston.redhat.com> <20060223160518.GA13799@devserv.devel.redhat.com> <1140711491.24114.18.camel@daxter.boston.redhat.com> <604aa7910602230840t3805e76cq4e30630883b90c60@mail.gmail.com> <1140728488.13317.23.camel@daxter.boston.redhat.com> Message-ID: <604aa7910602231342l65cba1fbm1803c325e806901a@mail.gmail.com> On 2/23/06, David Zeuthen wrote: > There is not really an easy way to do this yet. But someday we'll have > nice introspection and a generic browser UI for these. Someday I hope to have a pony. -jef"until there are introspection tools dbus-send scripting difficulty >> rocket science difficulty. I doubt the mythbusters could get dbus-send to work..but they sure have fun building water bottle rockets"spaleta From alan at redhat.com Thu Feb 23 21:46:23 2006 From: alan at redhat.com (Alan Cox) Date: Thu, 23 Feb 2006 16:46:23 -0500 Subject: Virtual machine software for Fedora testing? In-Reply-To: <1cef3e950602231322u3c43f267k1a08290cf8755c47@mail.gmail.com> References: <1cef3e950602231322u3c43f267k1a08290cf8755c47@mail.gmail.com> Message-ID: <20060223214623.GC11091@devserv.devel.redhat.com> On Thu, Feb 23, 2006 at 09:22:11PM +0000, Joe Desbonnet wrote: > Is there any free virtual machine software (like VMWare) that can be > used for testing Fedora installation? qemu, although it isnt the fastest system on the planet. From kwade at redhat.com Thu Feb 23 22:54:37 2006 From: kwade at redhat.com (Karsten Wade) Date: Thu, 23 Feb 2006 14:54:37 -0800 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <43FE192C.9000805@hotmail.com> References: <43FD0AC0.2090702@redhat.com> <43FE192C.9000805@hotmail.com> Message-ID: <1140735278.8018.116.camel@erato.phig.org> On Thu, 2006-02-23 at 15:21 -0500, Jack Tanner wrote: > This sounds like an incredibly useful thing to have in the release notes > for FC5, perhaps in abbreviated form. > > CC'ing relnotes@ as per instructions at > http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Process Thanks, haven't seen it come in yet, but I decided to file a bug report to work from[1]. We'll put a short, descriptive, action-oriented report in the release notes beats (fp.o/wiki/Docs/Beats/Xorg) and probably paste Mike's essay in it's entirety on another Wiki page to reference. cheers - Karsten [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182677 -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From williams at redhat.com Thu Feb 23 23:21:18 2006 From: williams at redhat.com (Clark Williams) Date: Thu, 23 Feb 2006 17:21:18 -0600 Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) In-Reply-To: <20060223183623.GB68343@dspnet.fr.eu.org> References: <20060223172846.GB58121@dspnet.fr.eu.org> <604aa7910602231008g5f188097t26eae60d82a33598@mail.gmail.com> <20060223183623.GB68343@dspnet.fr.eu.org> Message-ID: <1140736878.27282.28.camel@localhost.localdomain> On Thu, 2006-02-23 at 19:36 +0100, Olivier Galibert wrote: > On Thu, Feb 23, 2006 at 01:08:34PM -0500, Jeff Spaleta wrote: > > On 2/23/06, James Morris wrote: > > > Can I ask what your threat model is? > > > > Primary threat: bear attacks > > Secondary threat: moose attacks > > Thankfully I don't have a sister. Where did I put that interspace toothbrush... -- Clark Williams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From tmus at tmus.dk Fri Feb 24 00:02:21 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 24 Feb 2006 01:02:21 +0100 Subject: Virtual machine software for Fedora testing? In-Reply-To: <1140730626.4203.4.camel@ignacio.lan> References: <1cef3e950602231322u3c43f267k1a08290cf8755c47@mail.gmail.com> <43FE28A2.20906@cygnusx-1.org> <1140730626.4203.4.camel@ignacio.lan> Message-ID: Ignacio Vazquez-Abrams wrote: > On Thu, 2006-02-23 at 13:26 -0800, Nathan Grennan wrote: >> VMware GSX server: >> Now free, but the new free version is still in beta last I heard. > > No, VMware Server is gratis. VMware GSX is a separate product. > > VMware Server is VMware GSX (next generation, so essentially just a new version of the same product - GSX is being discontinued for all i know). /Thomas From tjarls at iee.lu Fri Feb 24 00:07:27 2006 From: tjarls at iee.lu (Charles Lopes) Date: Fri, 24 Feb 2006 01:07:27 +0100 Subject: Where did all my memory go? In-Reply-To: <1140705737.4672.59.camel@laptopd505.fenrus.org> References: <43FDC0D5.1050901@cornell.edu> <1140703784.4957.24.camel@xpc.home.erwinrol.com> <43FDC3BF.8090101@cornell.edu> <1140705737.4672.59.camel@laptopd505.fenrus.org> Message-ID: <43FE4E3F.3020000@iee.lu> Arjan van de Ven wrote: > On Thu, 2006-02-23 at 09:16 -0500, Ivan Gyurdiev wrote: > >>> And how is anybody here going to be able to debug or even only guess >>> what is wrong when using a kernel like that ? >>> >>> >> Well, I would assume, by having a better idea about how memory >> allocations work, and how they can be tracked, people could hint me as >> to how to figure out what's eating all the memory (since the top command >> isn't helping). Maybe three's a command I don't know about, or /proc >> statistics that could explain what's happening. If I knew how to debug >> the problem I wouldn't be asking the question, would I? >> >> I guess I should cc Steve Grubb on this, since the kernel does include >> lspp patches. >> > > also ask nvidia and madwifi for help first I suppose ;) > > Sure he's got these infamous modules. But he's not asking for someone to solve his problem but for information on how he could do it. Or does it mean that, just because he took the risk to use these modules, he should be denied the information he seeks. So please, would anyone be so kind as to explain how to track such leaks. I, for one, would be interested in knowing how to track them too. After three days, I get this: 3037932 3036704 99% 0.04K 33021 92 132084K biovec-1 3037920 3036816 99% 0.12K 101264 30 405056K bio I guess my sin is to have LVM on the top of MD RAID1. From enrico.scholz at informatik.tu-chemnitz.de Fri Feb 24 00:12:02 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 24 Feb 2006 01:12:02 +0100 Subject: Virtual machine software for Fedora testing? In-Reply-To: <1cef3e950602231322u3c43f267k1a08290cf8755c47@mail.gmail.com> (Joe Desbonnet's message of "Thu, 23 Feb 2006 21:22:11 +0000") References: <1cef3e950602231322u3c43f267k1a08290cf8755c47@mail.gmail.com> Message-ID: <87bqwx1up9.fsf@kosh.bigo.ensc.de> jdesbonnet at gmail.com ("Joe Desbonnet") writes: > Is there any free virtual machine software (like VMWare) that can be > used for testing Fedora installation? Linux-VServer (http://linux-vserver.org/) should have good Fedora Core support (host and guest). Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 482 bytes Desc: not available URL: From mknepher at bluethingy.com Fri Feb 24 00:23:49 2006 From: mknepher at bluethingy.com (Michael Knepher) Date: Thu, 23 Feb 2006 16:23:49 -0800 Subject: Notification bubble Message-ID: <1140740629.32082.18.camel@lionel-hutz.darnell.group> At some point during the Gnome 2.13.x development cycle, the notification bubbles were changed to an irregularly shaped balloon like this: http://www.bluethingy.com/linux/bubble2.png (as seen on my up-to-date rawhide install) While in the latest preview for gnome-2.14, the bubbles appear to have reverted to the older style: http://www.gnome.org/~davyd/gnome-2-14/images/libnotify.png I've noticed that dapper also has the "new old" bubbles. Is my system messed up, is the gnome-2.14 preview incorrect, or is Fedora going with the hideous blue balloons? From linux_4ever at yahoo.com Fri Feb 24 02:38:41 2006 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 23 Feb 2006 18:38:41 -0800 (PST) Subject: Where did all my memory go? In-Reply-To: <1140703784.4957.24.camel@xpc.home.erwinrol.com> Message-ID: <20060224023841.95768.qmail@web51510.mail.yahoo.com> >And how is anybody here going to be able to debug or even only guess >what is wrong when using a kernel like that ? The first step is to reboot onto a "normal" kernel and see if the same thing happens. If it does, there's a problem in the base kernel or some app. If it does not recur, then we start removing patches from the lspp kernel and see which one is guilty. The lspp kernel is a test kernel that has audit and lspp patches that are being tested prior to sending to the -mm tree. Because they are being tested, they very well could be at fault. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From pjones at redhat.com Thu Feb 23 23:18:21 2006 From: pjones at redhat.com (Peter Jones) Date: Thu, 23 Feb 2006 18:18:21 -0500 Subject: Results for install and remove tests for FC-Devel In-Reply-To: References: <43FC3ECA.9020100@redhat.com> <20060222140044.GA2959@free.fr> <43FC7E02.1000705@volny.cz> <1140676740.15913.3.camel@localhost.localdomain> Message-ID: <1140736702.4078.5.camel@localhost.localdomain> On Thu, 2006-02-23 at 09:48 -0700, Orion Poplawski wrote: > Peter Jones wrote: > > Yeah, but coreutils is a mandatory component of the "core" group in > > comps. It will always be at the top of the input to tsort, and tsort > > won't move it later except when it's inserting something above it to > > satisfy a coreutils (or the 4 packages in front of it) dependency. > > > > comps is gone. No, hdlist is gone. The package groups come from comps.xml, and unless you write yourself a really bogus kickstart file the initial package set is populated in the order from comps, which means you should have the packages in core first. That's *before* the depsolver and ordering run. > It's all yum depsolver ordering now. Yes, but it's still a tsort, and the list before sorting is still populated according to the order in comps. > I just did a fresh install of FC5T3 and avahi was installed before > coreutils, and thus the post script broke. A bug has been filed > against avahi. This is a different bug. -- Peter From tla-ml at rasmil.dk Fri Feb 24 07:04:32 2006 From: tla-ml at rasmil.dk (Tim Lauridsen) Date: Fri, 24 Feb 2006 08:04:32 +0100 Subject: python and rpm In-Reply-To: <13dbfe4f0602230749o277329ffu1754b4eaa7826c1e@mail.gmail.com> References: <13dbfe4f0602230749o277329ffu1754b4eaa7826c1e@mail.gmail.com> Message-ID: <43FEB000.3020403@rasmil.dk> Chitlesh GOORAH wrote: > hai there > i got a question related with rpm > > for mi in ts.dbMatch ('name', 'kernel'): > > it searches for kernel > good. now I want it to search for 'hypervisor' ? > > it is not a 'release' > > how should i proceed? > > -- > http://clunixchit.blogspot.com > > What about something like this for mi in ts.dbMatch ('name', 'kernel'): name = mi['name'] if name.find('hypervisor') <> -1: # Do the stuff Tim Lauridsen From igorm5 at vip.hr Fri Feb 24 07:22:22 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Fri, 24 Feb 2006 08:22:22 +0100 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <604aa7910602230013h45d90f4bg7526ac0faaff041e@mail.gmail.com> References: <43FD0AC0.2090702@redhat.com> <43FD6CED.9040703@vip.hr> <604aa7910602230013h45d90f4bg7526ac0faaff041e@mail.gmail.com> Message-ID: <43FEB42E.4050201@vip.hr> Jeff Spaleta wrote: > On 2/23/06, Igor Jagec wrote: >>What if we uninstall the official nVidia tarball and install Livna >>nvidia package, do we back things in order? Or it takes some extra >>manual work? > If you ever install from the nvidia tarball.. you have to reinstall > the Core mesa packages to make sure the Core mesa libraries are put > back as expected. The livna packages prevent problems... they do not > fix the problems caused by tarball based installs. The livna packages > by design do not touch the library files owned by Core packages so > they can not fix problems associated with vendor tarball installs > overwriting those libraries. I didn't know until now, thanks. I switched recently to nVidia tarball during the stability issue using tv out full screen and I thought I'll solve the problem that way, which I didn't :-/ I was lazy afterwards to bring Livna package back. I usually recompile Livna nvidia-glx srpm package. But the funny thing is that I've never seen some official nvidia-glx package for RHEL. That can be an issue if original nVidia tarballs make problems, and people are paying for that product (RHEL). I know that I can rebuild Livna srpm package on RHEL but I've never seen some official recommendation, or something for installing nVidia propriatery driver on RHEL. -- Igor Jagec From igorm5 at vip.hr Fri Feb 24 07:17:17 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Fri, 24 Feb 2006 08:17:17 +0100 Subject: Ralink rt2500, can't load module In-Reply-To: <1140718268.2305.21.camel@aurora.localdomain> References: <43FB7DC9.8060307@vip.hr> <1140559789.3082.37.camel@laptopd505.fenrus.org> <1140591640.2284.13.camel@aurora.localdomain> <43FCDA81.80703@vip.hr> <43FCFBE3.9030801@insitesinc.com> <43FD62ED.7070701@vip.hr> <43FDD1CE.5000208@insitesinc.com> <1140718268.2305.21.camel@aurora.localdomain> Message-ID: <43FEB2FD.1000707@vip.hr> It did not help :-/ I gues I'll have to wait for rt2x00 guys, or Ralink guys, to solve that problem. I'm just warried if they don't fix that untill FC5 is released. Thanks anyway. Trever L. Adams ka?e: > The below patch is NOT the correct solution. The solutions is to fix up > the calls. > > The new format for module_param is module_param(NAME, TYPE, PERMISSION); > > So, the NAME is obvious, it stays the same. The TYPE is one of (byte, > short, ushort, int, uint, long, ulong, charp, bool or invbool). > > I just now found this http://lwn.net/Articles/22197/ . It answers all > the questions of how to do the fix. I wish I would have found this a > month ago when I was making the driver work. It would have answered my > question in minutes instead of the two hours it took me to track down. > > Trever > > On Thu, 2006-02-23 at 09:16 -0600, Michael Favia wrote: > >>Index: rtmp_main.c >>=================================================================== >>RCS file: /cvsroot/rt2400/source/rt2500/Module/rtmp_main.c,v >>retrieving revision 1.64 >>diff -u -r1.64 rtmp_main.c >>--- rtmp_main.c 9 Feb 2006 23:42:10 -0000 1.64 >>+++ rtmp_main.c 22 Feb 2006 23:33:41 -0000 >>@@ -58,8 +58,8 @@ >> MODULE_PARM_DESC(debug, "Enable level: accepted values: 1 to switch debug on, 0 to switch debug off."); >> >> static char *ifname = NULL ; >>-MODULE_PARM(ifname, "s"); >>-MODULE_PARM_DESC(ifname, "Network device name (default ra%d)"); >>+//MODULE_PARM(ifname, "s"); >>+//MODULE_PARM_DESC(ifname, "Network device name (default ra%d)"); >> >> // Following information will be show when you run 'modinfo' >> MODULE_AUTHOR("http://rt2x00.serialmonkey.com"); > > > -- > "Stop searching forever. Happiness is just next to you." -- Unknown > -- Igor Jagec From buildsys at redhat.com Fri Feb 24 08:23:36 2006 From: buildsys at redhat.com (Build System) Date: Fri, 24 Feb 2006 03:23:36 -0500 Subject: rawhide report: 20060224 changes Message-ID: <200602240823.k1O8Na44009103@porkchop.devel.redhat.com> Updated Packages: anaconda-10.92.10-1 ------------------- * Thu Feb 23 2006 Jeremy Katz - 10.92.10-1 - more bogl removal (dcantrel) - make the exception dumping less braindead about things we don't want dumped (clumens) - add backtrace handler to anaconda (pjones) - fix warnings with new yum in pkgorder - make conditional packages on deps work (pnasrat) - suppress some warnings (dcantrel) - text mode language fixes (dcantrel) * Thu Feb 23 2006 Jeremy Katz - 10.92.9-1 - Fix text mode traceback (dcantrel) - Skip a few more things in traceback dumps - Attempt to fix pkgorder so that we require less CDs for "normal" installs bluez-libs-2.25-1 ----------------- * Thu Feb 23 2006 David Woodhouse - 2.25-1 - Update to bluez-libs 2.25 cpuspeed-1:1.2.1-1.33 --------------------- * Thu Feb 23 2006 Dave Jones - Fix broken init script. (Alexandre Oliva) [#182691] Taking ugly shell script to the next level. evolution-data-server-1.5.91-1 ------------------------------ * Tue Feb 14 2006 David Malcolm - 1.5.91-1 - 1.5.91 gnome-applets-1:2.13.4-4 ------------------------ * Thu Feb 23 2006 Matthias Clasen - 2.13.4-4 - Make the stock ticker work with gcc 4.1 (#179528) kernel-2.6.15-1.1977_FC5 ------------------------ * Thu Feb 23 2006 Dave Jones - 2.6.16rc4-git6 libbtctl-0.6.0-5 ---------------- * Thu Feb 23 2006 Matthias Clasen 0.6.0-5 - try a fix for (#179413) * Thu Feb 23 2006 Harald Hoyer 0.6.0-2 - rebuild * Thu Feb 16 2006 Harald Hoyer 0.6.0-1 - version 0.6.0 xen-3.0.1-0.20060208.fc5.3 -------------------------- * Thu Feb 23 2006 Jeremy Katz - 3.0.1-0.20060208.fc5.3 - add patch to ensure we get a unique fifo for boot loader (#182328) - don't try to read the whole disk if we can't find a partition table with pygrub - fix restarting of domains (#179677) Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15-5.FC5.4.i686 requires kernel = 0:2.6.15-1.1955_FC5 GFS-kernel - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5 GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5smp cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp gnbd-kernel - 2.6.15-5.FC5.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp libbtctl - 0.6.0-5.i386 requires libopenobex.so.1 struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.i386 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.i386 requires tomcat4 Broken deps for ia64 ---------------------------------------------------------- libbtctl - 0.6.0-5.ia64 requires libopenobex.so.1()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.ia64 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.ia64 requires tomcat4 vconfig - 1.9-1.1.ia64 requires libc.so.6 vconfig - 1.9-1.1.ia64 requires libc.so.6(GLIBC_2.0) Broken deps for ppc ---------------------------------------------------------- libbtctl - 0.6.0-5.ppc requires libopenobex.so.1 struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.ppc requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.ppc requires tomcat4 Broken deps for ppc64 ---------------------------------------------------------- emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi libbtctl - 0.6.0-5.ppc64 requires libopenobex.so.1()(64bit) struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.ppc64 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.ppc64 requires tomcat4 vconfig - 1.9-1.1.ppc64 requires libc.so.6 vconfig - 1.9-1.1.ppc64 requires libc.so.6(GLIBC_2.0) Broken deps for s390 ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.s390 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.s390 requires tomcat4 Broken deps for s390x ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.s390x requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.s390x requires tomcat4 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 libbtctl - 0.6.0-5.i386 requires libopenobex.so.1 libbtctl - 0.6.0-5.x86_64 requires libopenobex.so.1()(64bit) struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.x86_64 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.x86_64 requires tomcat4 From che666 at gmail.com Fri Feb 24 08:29:30 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Fri, 24 Feb 2006 09:29:30 +0100 Subject: Unite Non-free repos (Was: Re: Non-free Extras?) In-Reply-To: <1140717191.2140.17.camel@localhost.localdomain> References: <43FBA1CD.4020908@gmail.com> <43FC1F67.7080607@argo.co.il> <20060222120630.GD20029@devserv.devel.redhat.com> <43FC5A1B.4070106@cornell.edu> <43FCC1D2.4020206@gmail.com> <1140641962.4192.102.camel@localhost.localdomain> <1140717191.2140.17.camel@localhost.localdomain> Message-ID: 2006/2/23, Thorsten Leemhuis : > Am Donnerstag, den 23.02.2006, 18:23 +0100 schrieb Rudolf Kastl: > > 2006/2/22, Thorsten Leemhuis : > > > Am Mittwoch, den 22.02.2006, 14:56 -0500 schrieb Eric Mesa: > > > > well id be happy if just planetccrma would be slowly merged into > > extras... the main blocker seems to be the realtime kernel module as > > far as i can see. > > Well, we had a discussion about "kernels in Fedora Extras" on this list > some months ago. I don't think that we should provide them there. But > that's debatable. And even if we agree not to ship them: planetccrma > could still ship the kernels and we could merge everything else into > extras if possible. the question is if its really necassery to build a seperate kernel instead of building missing modules vs the current one. and if thats necassery one would have to deeply dig into it why and see if theres a possibility to work around that. i am not sure in that special case myself. Then again it might be helpful probably to have a 3rd party repo just doing kernel modules that are out of the tree etc. theres various functionality i cant seem to get with the current standard upstream kernel. e.g. alsa bluetooth module for pairing and using my bluetooth headset. maybe theres anothe r way to achieve that though i yet still have to find it.. another deal is visdn. i need a proper isdn stack beeing able to make bri cards working in te and nt mode since the current isdn stack is incomplete and broken for my purposes. I do also agree that this stuff has to be fixed upstream i just dont see it happen and actually i dont want to wait another few years to have hardware that could be working having not working at all for the purposes i need it. > > > actually from the other repos only a few packages are missing that > > could be contributed to extras and youd be nearly there. besides some > > kernel modules atrpms provides e.g. > > Well, the confusion for the user remains as long as freshrpms, atrpms > rpmforge and livna exist in their current state. I've seen multiple > users that didn't know that repo mixing can result in "interesting > results". Most users hit those sooner or later and ran away screaming to > Ubuntu or Suse. i agree i just dont see a way to prevent that besides providing the same functionality with a working set of repos. So basically if the stuff would be in extras people wouldnt add yet another repo just for the fun of it if it wouldnt be necassery. one has to question why the repos exist and what they provide to the user to make em enable them. sure for the reknown repos there are just a big number of fans that "traditionally" enable them because they have had good experiences with it in the past and their stuff working thats something no one will be able to prevent. regards, Rudolf Kastl > > CU > thl > -- > Thorsten Leemhuis > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From rmy at tigress.co.uk Fri Feb 24 09:44:59 2006 From: rmy at tigress.co.uk (Ron Yorston) Date: Fri, 24 Feb 2006 09:44:59 GMT Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) Message-ID: <200602240944.k1O9ixln016849@tiffany.internal.tigress.co.uk> Davide Bolcioni wrote: >I think we might be aiming at the wrong target, especially in >the case of corporate admins. Target application developers, >not admins: applications must work without requiring any modification >to the system and adapt accordingly. Application developers? What has SELinux policy got to do with application developers? The targeted policy "focuses on locking down specific daemons, especially ones vulnerable to attack or to devastating a system if broken or compromised". (From the SELinux FAQ on fedora.redhat.com.) That's a tiny subset of applications. Ron From mharris at mharris.ca Fri Feb 24 09:45:41 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Fri, 24 Feb 2006 04:45:41 -0500 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <1140705297.3803.158.camel@pmac.infradead.org> References: <43FD0AC0.2090702@redhat.com> <1140705297.3803.158.camel@pmac.infradead.org> Message-ID: <43FED5C5.5090407@mharris.ca> David Woodhouse wrote: > On Wed, 2006-02-22 at 20:07 -0500, Mike A. Harris wrote: > >>Both ATI and Nvidia, and perhaps even other 3rd party drivers out there >>come in some form of tarball or equivalent form from the particular >>vendor. > > > The Intel driver is worse than that, in some ways. In that case you > don't even need to seek out and install separate software; a clean > Fedora installation out of the box will run binary-only code supplied by > your board manufacturer, without really giving you much clue that it's > doing so. > > I recently purchased a board with Intel i915 graphics, because I was led > to believe that it had a fully open source driver -- and now I've found > that all the mode setup is in binary-only code. So I can't make it do > the PAL output modes for which I purchased it. Yeah, that's a situation that continues to suck bigtime. The i[89]resolution utilities hack around it in some cases, but it's still just an ugly hack, and doesn't work all the time. Oddly enough though, the i810 driver is currently the most video vendor supported driver. Hopefully Intel will change their tune about mode programming documentation in the future. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Fri Feb 24 09:48:09 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Fri, 24 Feb 2006 04:48:09 -0500 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <20060223143934.GA4138@devserv.devel.redhat.com> References: <43FD0AC0.2090702@redhat.com> <1140705297.3803.158.camel@pmac.infradead.org> <20060223143934.GA4138@devserv.devel.redhat.com> Message-ID: <43FED659.3030200@mharris.ca> Alan Cox wrote: > On Thu, Feb 23, 2006 at 02:34:57PM +0000, David Woodhouse wrote: > >>Fedora installation out of the box will run binary-only code supplied by >>your board manufacturer, without really giving you much clue that it's >>doing so. > > > Correct. Each intel board has board specific analogue circuitry and interfaces > which are driven via a BIOS interface. X would need a driver for each > motherboard (and potentially each board rev) to do anything else Yes, the driver may need to become more complicated in order to do direct mode programming, however users of other proprietary OSs do have video drivers that give them what they want/need, so it is possible in theory to have OSS drivers that do the same. There's no reason it needs to be multiple separate drivers however, conditional codepaths and autodetection within a single driver should be able to handle it, at least in theory. All smoke until Intel does something that allows the situation to change though. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Fri Feb 24 10:03:36 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Fri, 24 Feb 2006 05:03:36 -0500 Subject: Low OpenGL performance In-Reply-To: <36006.194.94.224.254.1140611334.squirrel@jose.freesurf.fr> References: <36006.194.94.224.254.1140611334.squirrel@jose.freesurf.fr> Message-ID: <43FED9F8.80502@mharris.ca> Joachim Frieben wrote: > After installing FC5T3 including updates on 2 different machines, I am > puzzled by the surprisingly poor OpenGL performance when running the > "glxgears" command: > > IBM ThinkPad T23 [SuperSavage IX/C SDR]: 115 FPS > > when other users report values of at least 240 FPS. Similarly for a > > PR440FX based SPM system [Radon 7200 PCI]: 160 FPS > > when I used to achieve 360 FPS for earlier releases. In both cases, "DRI" is > enabled. "LIBGL_DEBUG" is set to "verbose", and "glxinfo" output looks ok. > Moreover, I booted with "enforcing=0" to avoid any "SELinux" trouble ... . > > Any ideas? Similar observations? It's generally a good idea to subscribe to the DRI and Mesa mailing lists if experiencing GL performance issues or other problems. The IRC channel #dri-devel on freenode.net is also quite useful. That's a direct pipe to the developers, who are generally quite helpful and often provide troubleshooting tips, etc. Hope this helps. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Fri Feb 24 10:19:13 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Fri, 24 Feb 2006 05:19:13 -0500 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <43FD6CED.9040703@vip.hr> References: <43FD0AC0.2090702@redhat.com> <43FD6CED.9040703@vip.hr> Message-ID: <43FEDDA1.9070709@mharris.ca> Igor Jagec wrote: > Mike A. Harris wrote: > > >>Both ATI and Nvidia, and perhaps even other 3rd party drivers out there >>come in some form of tarball or equivalent form from the particular >>vendor. Most users seem to favour the hardware vendor supplied drivers >>directly, rather than using more sanely packaged 3rd party packages that >>contain the same drivers. This is very unfortunate, because installing >>these 3rd party tarball driver installations is very harmful to your >>clean OS installation. >>Both ATI and Nvidia's proprietary video driver installation utilities >>replace the Red Hat supplied libGL library with their own libGL. >>Nvidia's driver installs a replacement libglx.a X server module, >>removing the Red Hat supplied X.Org module in the process. ATI's >>driver may or may not replace libglx.a with it's own, I haven't checked >>(but if someone could confirm that, I'd appreciate knowing for certain). > > > What if we uninstall the official nVidia tarball and install Livna > nvidia package, do we back things in order? Or it takes some extra > manual work? Speaking about libglx.a and stuff. I mean, there it would > be insane if we had to reinstall the whole system because of that. Thanks. Using the livna ati/nvidia rpms is probably the cleanest method currently of installing and using the proprietary drivers. Having said that, you can still have various problems still. Here are some off the top of my head: 1) Using the proprietary driver, then switching to the OSS driver by editing xorg.conf and changing from "nvidia" to "nv". This will switch 2D drivers, but unless you comment out the config file changes to ModulePath, Nvidia's proprietary modules such as libglx.a will still get loaded, and will complain in the X server log file. Not sure if this actually causes any real problems or not, but as soon as I see it in a log file, the bug report becomes blacklisted. 2) Using the proprietary driver (any vendor) and switching to an OSS driver, without doing a complete full reboot of the system, and ensuring their kernel modules do not ever load, will mean the OSS driver is using the hardware in whichever state the proprietary driver happened to leave it in. This can cause problems if the hardware is not in the state the OSS driver assumes it to be in. Likewise, once a proprietary kernel module has been loaded, it _owns_ the kernel. Even if you remove it with rmmod, it has been in the kernel's memory space and could have done absolutely anything while it was there. The proprietary kernel modules for video drivers do _insane_ crazy stuff in the name of performance, which really screws with the kernel's innards. For that reason, if you're using the livna rpms, and switching from proprietary to OSS modules, the best thing to do probably is: 1) Disable any kernel modules from loading if they load at init time by initscripts or similar, or from modprobe.conf. 2) Make a backup copy of xorg.conf in case you want to use it again later, or reference it for anything. 3) Run "system-config-display --reconfig" which will generate a completely fresh config file. DO NOT EDIT THIS FILE. Test it first, and if there are custom tweaks you wish to make, make them _ONLY_ after you have tested the stock xorg.conf that system-config-display generates. 4) Reboot the computer or power it right off and back on. This is critically important to ensure the hardware is reset to factory power on defaults. A lot of people refuse to reboot, or are strongly against the idea of doing so, with the idea that Linux never needs to be rebooted. While Linux generally doesn't need to be rebooted, there are sometimes some very good benefits to doing so, and this is one of those cases. Don't fight this step in a childish quest to have higher uptime or some other useless trivial reason, as you'll may end up pulling your hair out trying to troubleshoot problems that rebooting would cure instantly. Focus on solving the real problem, and just hit the switch. Hope this helps. TTYL P.S. As always, feel free to add this info to the wiki, or paraphrase and polish, yada yada if desired. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Fri Feb 24 10:23:05 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Fri, 24 Feb 2006 05:23:05 -0500 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <43FD78EC.4080104@3di.it> References: <43FD0AC0.2090702@redhat.com> <43FD78EC.4080104@3di.it> Message-ID: <43FEDE89.5050301@mharris.ca> Davide Bolcioni wrote: > Mike A. Harris wrote: > >> Both ATI and Nvidia's proprietary video driver installation utilities >> replace the Red Hat supplied libGL library with their own libGL. > > > Could SELinux be used to prevent this and, more generally, disallow > replacement of rpm-controlled files even by the root user ? One of the SElinux guys can probably answer that better than I, as I don't use SElinux personally, and my knowledge of what all it can do, and how to make it do that, is rather limited. As some of our other developers have mentioned before, it's black voodoo magic. ;o) chattr +i on the files might do the job, but then I suppose nvidia's installer would just chattr -i them circumventing it. It's far easier to just clearly state that 3rd party drivers are not supported in any way shape or form, and give people the right expectations. Then they may or may not like it, but at least they know where things stand. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Fri Feb 24 10:26:47 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Fri, 24 Feb 2006 05:26:47 -0500 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <200602230958.19039.lamont@gurulabs.com> References: <43FD0AC0.2090702@redhat.com> <43FD6CED.9040703@vip.hr> <6280325c0602230010w7f46f8b0gc3592e14fb5b6ddb@mail.gmail.com> <200602230958.19039.lamont@gurulabs.com> Message-ID: <43FEDF67.9090607@mharris.ca> Lamont R. Peterson wrote: > On Thursday 23 February 2006 01:10am, n0dalus wrote: > >>On 2/23/06, Igor Jagec wrote: > > [snip] > >>Essentially, after installing livna's packages instead, you would need >>to do an rpm -Va on various packages to ensure that the files hadn't >>been replaced (If they have, reinstall those packages). > > > Not to nit-pick, but running rpm -Va will check *all* packages; that's what > the -a switch does. Same for rpm -qa listing all packages. Of course, you > can also do: > > rpm -qa kernel* > > to see all packages that begin with "kernel". If you want to verify only > certain packages with rpm, run: > > rpm -V package1 package2 package3 > > BTW: rpm -Va will take a long time to run. Users who are technically inclined enough to optimize the rpm verify to a subset of all packages that just encompass all X packages, are of course free to do so. :o) rpm -Va gets them all, without having to have a big explanation, or provide a list of all of the relevent packages however. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Fri Feb 24 10:29:43 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Fri, 24 Feb 2006 05:29:43 -0500 Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) In-Reply-To: <1140718384.3722.28.camel@localhost.localdomain> References: <20060223172846.GB58121@dspnet.fr.eu.org> <604aa7910602231008g5f188097t26eae60d82a33598@mail.gmail.com> <1140718384.3722.28.camel@localhost.localdomain> Message-ID: <43FEE017.4080400@mharris.ca> Michael Tiemann wrote: > On Thu, 2006-02-23 at 13:08 -0500, Jeff Spaleta wrote: > >>On 2/23/06, James Morris wrote: >> >>>Can I ask what your threat model is? >> >>Primary threat: bear attacks >>Secondary threat: moose attacks > > > What if somebody approaches you holding a banana? Disarm the banana. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From tmus at tmus.dk Fri Feb 24 11:22:52 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 24 Feb 2006 12:22:52 +0100 Subject: Notification bubble In-Reply-To: <1140740629.32082.18.camel@lionel-hutz.darnell.group> References: <1140740629.32082.18.camel@lionel-hutz.darnell.group> Message-ID: Michael Knepher wrote: > At some point during the Gnome 2.13.x development cycle, the > notification bubbles were changed to an irregularly shaped balloon like > this: > > http://www.bluethingy.com/linux/bubble2.png > > (as seen on my up-to-date rawhide install) > > While in the latest preview for gnome-2.14, the bubbles appear to have > reverted to the older style: > > http://www.gnome.org/~davyd/gnome-2-14/images/libnotify.png > > I've noticed that dapper also has the "new old" bubbles. > > Is my system messed up, is the gnome-2.14 preview incorrect, or is > Fedora going with the hideous blue balloons? > Without knowing for sure i would think that this was probably themable and you're seeing differences in themes, perhaps? Just a wild guess! /Thomas From benjy.grogan at gmail.com Fri Feb 24 11:42:45 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Fri, 24 Feb 2006 06:42:45 -0500 Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) In-Reply-To: <200602240944.k1O9ixln016849@tiffany.internal.tigress.co.uk> References: <200602240944.k1O9ixln016849@tiffany.internal.tigress.co.uk> Message-ID: On 2/24/06, Ron Yorston wrote: > > Davide Bolcioni wrote: > >I think we might be aiming at the wrong target, especially in > >the case of corporate admins. Target application developers, > >not admins: applications must work without requiring any modification > >to the system and adapt accordingly. > > Application developers? What has SELinux policy got to do with > application > developers? > > The targeted policy "focuses on locking down specific daemons, especially > ones vulnerable to attack or to devastating a system if broken or > compromised". (From the SELinux FAQ on fedora.redhat.com.) > > That's a tiny subset of applications. > That was my understanding of SELinux. You could run a crazy program that has root privileges, is hackable, has no SELinux policy, and all that effort was for nigh. Benji -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at camperquake.de Fri Feb 24 11:45:17 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 24 Feb 2006 12:45:17 +0100 Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) In-Reply-To: References: <200602240944.k1O9ixln016849@tiffany.internal.tigress.co.uk> Message-ID: <20060224124517.0fd0686e@dhcp05.addix.net> Hi. On Fri, 24 Feb 2006 06:42:45 -0500, Benjy Grogan wrote: > That was my understanding of SELinux. You could run a crazy program > that has root privileges, is hackable, has no SELinux policy, and all > that effort was for nigh. I think this is a question of policy. The "targeted" policy does what you describe, it just confines specific applications. You are free to use the reverse approach, though. From ivg2 at cornell.edu Fri Feb 24 11:58:45 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 24 Feb 2006 06:58:45 -0500 Subject: Selinux: (not) "Black Voodoo Magic?" In-Reply-To: <43FEDE89.5050301@mharris.ca> References: <43FD0AC0.2090702@redhat.com> <43FD78EC.4080104@3di.it> <43FEDE89.5050301@mharris.ca> Message-ID: <43FEF4F5.2060200@cornell.edu> >> >> Could SELinux be used to prevent this and, more generally, disallow >> replacement of rpm-controlled files even by the root user ? > > One of the SElinux guys can probably answer that better than I, as I > don't use SElinux personally, and my knowledge of what all it can > do, and how to make it do that, is rather limited. As some of our > other developers have mentioned before, it's black voodoo magic. Black Voodoo Magic? All those complains about how "selinux is hard", and "I have no idea how selinux works, I'm turning it off" make no sense to me. Selinux policy follows what your code does, and establishes a bound around what it's allowed to do. If you're able to understand thousands of lines of complex code (in a project such as the X server), then surely you can figure out the (much simpler) security box around it, and change it to your advantage. The job of the selinux developers (figure out each and every detail of X, so it will never leave the security box, and fail) seems harder to me. Ultimately a failure in selinux means that either (1) your application is doing something it shouldn't, or (2) the selinux developers' did not anticipate or understand that your application would need such privileges. Policy writing is a manual project at this time. Some people have mentioned to me that it might be possible to automate certain parts of it, but this isn't available today... I agree with the earlier poster, which said application developers should help with policy. If you are interested in that, you can look at: http://serefpolicy.sourceforge.net/, download the code, and at least have a look at the policy for your project (if one is available), and point out any critical flaws in it on the fedora-selinux list. I'm sure patches are also welcome. ======================== I'm not currently involved with policy development, so questions would be better directed at the selinux list. However, I have written some policy in the past, so here's what my suggestions would be (follow at your own risk): 1. policy is a collection of language rules, as described here: http://www.nsa.gov/selinux/papers/policy2/x107.html 2. later extended by Tresys to this: http://sepolicy-server.sourceforge.net/index.php?page=module-language 3. that are later processed through m4, which allows simulation of "functions" and "if-else" statements (now organized in modules, with api, which get compiled and linked in two steps) 4. reading all the above is very useful, but in the short run you can follow existing patterns to learn what's going on 5. everything that is not specifically allowed is denied 6. A typical rule is: allow { src1_t src2_t } { target1_t target2_t }:{ class1 class2 } { permission1 permission2 }. Things that end in _t are types - they're defined with the "type" language rule. class1, class2 are typically things like: file, dir, fifo_file, and are defined in flask/security_classes permission1, permission2 are specific to the above class, and are defined in flask/access_vectors. This rule allows subjects in { src1_t src2_t } to act on objects in { target1_t target2_t } of type { class1 class2 } in ways { permission1 permission2 }. The set notation above expands as a cartesian product. 7) Because m4 expansion is used, things are written in if-else statements (conditioned on things called booleans), and in functions/interfaces. This has the drawback of having a steep learning curve, because you might not be familiar with the other macros being called. I suggest use of grep, and http://serefpolicy.sourceforge.net/api-docs/ to figure it out. It would be absolutely wrong to write only low-level rules - the policy structure should model the program being confined. Things in a shared library should go into a shared interface. 8) Follow existing patterns. Interfaces go in the .if file (they take arguments $1, $2), other rules go in the .te file, file context labels go in the .fc file. 9) Important concepts are: domain transition (this is how you get out of your domain, and into another one, potentially causing havoc there). type transition (this is how your program sets the context of your files to something other than the parent directory, without modifying the application code - black magic! automatic chmod. very useful in practice) Grep for domtrans/filetrans/domain_auto_trans in the policy, I'm not sure what those are called nowdays, but it shouldn't be hard to figure it out. From emeric.maschino at jouy.inra.fr Fri Feb 24 12:03:13 2006 From: emeric.maschino at jouy.inra.fr (Emeric Maschino) Date: Fri, 24 Feb 2006 13:03:13 +0100 Subject: DRI permission problem Message-ID: <1140782593.5088.14.camel@localhost.localdomain> Hi, I'm running up-to-date Rawhide on my Itanium workstation. However, when I'm trying glxinfo as root or as user emeric, I'm getting: libGL error: open DRM failed (Operation not permitted) libGL error: reverting to (slow) indirect rendering X Error of failed request: GLXBadContext Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 22 Current serial number in output stream: 22 name of display: :0.0 I don't understand what's wrong with the permissions. As user emeric, ls -lZ /dev/dri/card0 gives: crw------- emeric root system_u:object_r:dri_device_t /dev/dri/card0 Furthermore, the DRI section in my xorg.conf file is as follows: Section "DRI" Group 0 Mode 0666 EndSection I've checked on a x86 FC4 system: the DRI section is identical. None of the hints found with Google worked for me. Does anybody understand what's wrong? Is this an ia64-specific issue? Many thanks, ?meric From ivg2 at cornell.edu Fri Feb 24 12:07:28 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 24 Feb 2006 07:07:28 -0500 Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) In-Reply-To: <20060224124517.0fd0686e@dhcp05.addix.net> References: <200602240944.k1O9ixln016849@tiffany.internal.tigress.co.uk> <20060224124517.0fd0686e@dhcp05.addix.net> Message-ID: <43FEF700.7070905@cornell.edu> >> That was my understanding of SELinux. You could run a crazy program >> that has root privileges, is hackable, has no SELinux policy, and all >> that effort was for nigh. >> It goes more like: - "I have a crazy program that has root privileges, is hackable, has no SELinux policy" - "I'll write a selinux policy for it" - "Now the program's still hackable, but at least it doesn't break anything else when it gets get hacked" I'm not sure what you expect to happen - policy should write itself? Programs without a policy run in a high privilege domain, because we still want those programs to work, even though nobody has written a policy for them. It's easy to restrict those programs to run in a low privilege domain. Then they wouldn't work at all, and you'd only be able to run confined programs - I doubt this is what you want. Note that strict policy confines a lot more things that targeted does - it's meant to be used in a locked-down environment. (Unfortunately it seems broken at the moment, but I'm sure most of it will be fixed by FC5). From ivg2 at cornell.edu Fri Feb 24 12:14:43 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 24 Feb 2006 07:14:43 -0500 Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) In-Reply-To: <200602240944.k1O9ixln016849@tiffany.internal.tigress.co.uk> References: <200602240944.k1O9ixln016849@tiffany.internal.tigress.co.uk> Message-ID: <43FEF8B3.6050803@cornell.edu> > Application developers? What has SELinux policy got to do with application > developers? > It has everything to do with application developers. The person that knows most about an application can write the best policy, which describes best what that application does, so that the application can work in a safe and controlled manner, without generating denials. > The targeted policy "focuses on locking down specific daemons, especially > ones vulnerable to attack or to devastating a system if broken or > compromised". (From the SELinux FAQ on fedora.redhat.com.) > > That's a tiny subset of applications. > Surely you've noticed how the number of those targets keep increasing with every release. They're all migrating over from strict policy. Anyway, the fact that it's a tiny subset of applications doesn't mean that it wouldn't be helpful to get developer review of the policy, and participation/patches. From ivg2 at cornell.edu Fri Feb 24 12:37:58 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 24 Feb 2006 07:37:58 -0500 Subject: Selinux: (not) "Black Voodoo Magic?" In-Reply-To: <43FEF4F5.2060200@cornell.edu> References: <43FD0AC0.2090702@redhat.com> <43FD78EC.4080104@3di.it> <43FEDE89.5050301@mharris.ca> <43FEF4F5.2060200@cornell.edu> Message-ID: <43FEFE26.6030309@cornell.edu> > > 7) Because m4 expansion is used, things are written in if-else > statements (conditioned on things called booleans), and in > functions/interfaces. This has the drawback of having a steep learning > curve, because you might not be familiar with the other macros being > called. I suggest use of grep, and > http://serefpolicy.sourceforge.net/api-docs/ to figure it out. It > would be absolutely wrong to write only low-level rules - the policy > structure should model the program being confined. Things in a shared > library should go into a shared interface. arg... correction: Booleans are not handled via m4 expansion, they are part of the language (because their state is determined at runtime, not at compile time). There's: m4 ifelse construct - for conditional policy generation language if construct - for booleans, conditional policy at runtime From chitlesh at fedoraproject.org Fri Feb 24 12:53:59 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Fri, 24 Feb 2006 13:53:59 +0100 Subject: rawhide report: 20060224 changes In-Reply-To: <200602240823.k1O8Na44009103@porkchop.devel.redhat.com> References: <200602240823.k1O8Na44009103@porkchop.devel.redhat.com> Message-ID: <13dbfe4f0602240453k5ef2dbetf04a669e786c9d50@mail.gmail.com> > Updated Packages: > > anaconda-10.92.10-1 > ------------------- > * Thu Feb 23 2006 Jeremy Katz - 10.92.10-1 > - more bogl removal (dcantrel) > - make the exception dumping less braindead about things we don't > want dumped (clumens) > - add backtrace handler to anaconda (pjones) > - fix warnings with new yum in pkgorder > - make conditional packages on deps work (pnasrat) > - suppress some warnings (dcantrel) > - text mode language fixes (dcantrel) > > * Thu Feb 23 2006 Jeremy Katz - 10.92.9-1 > - Fix text mode traceback (dcantrel) > - Skip a few more things in traceback dumps > - Attempt to fix pkgorder so that we require less CDs for "normal" installs > *** running anaconda *** While executing Kadischi : Traceback (most recent call last): File "/usr/sbin/anaconda", line 397, in ? signal.signal(signal.SIGSEGV, isys.handleSegv) AttributeError: 'module' object has no attribute 'handleSegv' *** Fatal error: anaconda returned non zero (256) exit code. Aborting execution. Cleaning up temporary files... Done. [root at goorah ~]# rpm -q anaconda anaconda-10.92.10-1 Sounds its broken :( -- http://clunixchit.blogspot.com From rmy at tigress.co.uk Fri Feb 24 12:58:16 2006 From: rmy at tigress.co.uk (Ron Yorston) Date: Fri, 24 Feb 2006 12:58:16 GMT Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) Message-ID: <200602241258.k1OCwG7D016999@tiffany.internal.tigress.co.uk> Ivan Gyurdiev wrote: >Anyway, the fact that it's a tiny subset of applications doesn't mean >that it wouldn't be helpful to get developer review of the policy, and >participation/patches. Quite so. But my concern isn't with the few developers working on critical infrastructure: by all means have them learn about SELinux and review policy. However, I don't think it's reasonable to expect application developers /in general/ to be responsible for making their applications work in the presence of SELinux, any more than one could expect corporate admins /in general/ to have a detailed understanding of SELinux policy. Ron From benjy.grogan at gmail.com Fri Feb 24 13:07:03 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Fri, 24 Feb 2006 08:07:03 -0500 Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) In-Reply-To: <43FEF700.7070905@cornell.edu> References: <200602240944.k1O9ixln016849@tiffany.internal.tigress.co.uk> <20060224124517.0fd0686e@dhcp05.addix.net> <43FEF700.7070905@cornell.edu> Message-ID: On 2/24/06, Ivan Gyurdiev wrote: > > > >> That was my understanding of SELinux. You could run a crazy program > >> that has root privileges, is hackable, has no SELinux policy, and all > >> that effort was for nigh. > >> > It goes more like: > - "I have a crazy program that has root privileges, is hackable, has no > SELinux policy" > - "I'll write a selinux policy for it" > - "Now the program's still hackable, but at least it doesn't break > anything else when it gets get hacked" > > I'm not sure what you expect to happen - policy should write itself? > > Programs without a policy run in a high privilege domain, because we > still want those programs to work, even though nobody has written a > policy for them. It's easy to restrict those programs to run in a low > privilege domain. Then they wouldn't work at all, and you'd only be able > to run confined programs - I doubt this is what you want. > > Note that strict policy confines a lot more things that targeted does - > it's meant to be used in a locked-down environment. > (Unfortunately it seems broken at the moment, but I'm sure most of it > will be fixed by FC5). I'm in favor of SELinux. I've heard that when writing these policies the developers have actually improved the applications themselves. They realized that an application didn't really need this or that permission and so they adjusted the code and wrote an even better policy. SELinux seems to have some use in debugging software. If people are afraid of SELinux I think what's need is more education on it. more "layman" articles getting across a few of the "ideas" behind SELinux. I think some hello world examples of writing an SELinux policy for a simple daemon would be good. Benji, Professional Layman -------------- next part -------------- An HTML attachment was scrubbed... URL: From che666 at gmail.com Fri Feb 24 13:16:37 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Fri, 24 Feb 2006 14:16:37 +0100 Subject: Low OpenGL performance In-Reply-To: <200602220946.16075.tbrinkman@sbcglobal.net> References: <1140611961.2384.226.camel@dragon.sys.intra> <48537.194.94.224.254.1140616662.squirrel@arlette.freesurf.fr> <200602220946.16075.tbrinkman@sbcglobal.net> Message-ID: 2006/2/22, Tom Brinkman : > On Wednesday 22 February 2006 08:57, Joachim Frieben wrote: > > Yes, for the "nv" driver, you do not obtain any hardware > > acceleration at all. > > Not quite true, an hasn't been for several years. What you don't > have with 'nv' is direct rendering (DRI). Needed for 3d/accel games. > Prior to SGI's contributions a few years ago, 'glxgears' wouldn't > even run at all. > (from glxinfo) > display: :0 screen: 0 > direct rendering: No > server glx vendor string: SGI > server glx version string: 1.2 > > > So, the values are still reasonable for pure > > soft rendering and equivalent for my own older hardware with "DRI" > > enabled! > > > > > I get 160/170 on nvidia [Quadro4 NVS AGP 8x]. Standard "nv" > > > driver, no nvidia driver. > > GeF4, nv driver, Athlon XP 3200+/400.. 380 / 390fps on the small > default window, but when run full screen, 1280x1024-24 it drops to > 27 / 30fps. > > -- > Tom Brinkman Corpus Christi, Texas > > -- umm care to elaborate what is hardware accelerated by the gpu with software rendering and the nv driver if the cpu does all the rendering? regards, Rudolf Kastl > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From ivg2 at cornell.edu Fri Feb 24 13:16:40 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 24 Feb 2006 08:16:40 -0500 Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) In-Reply-To: <200602241258.k1OCwG7D016999@tiffany.internal.tigress.co.uk> References: <200602241258.k1OCwG7D016999@tiffany.internal.tigress.co.uk> Message-ID: <43FF0738.8020904@cornell.edu> Ron Yorston wrote: > Ivan Gyurdiev wrote: > >> Anyway, the fact that it's a tiny subset of applications doesn't mean >> that it wouldn't be helpful to get developer review of the policy, and >> participation/patches. >> > > Quite so. But my concern isn't with the few developers working on > critical infrastructure: by all means have them learn about SELinux > and review policy. > > However, I don't think it's reasonable to expect application developers > /in general/ to be responsible for making their applications work in > the presence of SELinux, any more than one could expect corporate admins > /in general/ to have a detailed understanding of SELinux policy. > That depends on your point of view. If you consider selinux a feature to be used by a tiny subset of users (those "paranoid" about security, or within an environment that requires it), then you'd be right - I shouldn't need to worry about selinux if the majority of my target audience didn't use it. If you take the point of view that selinux will be widely deployed and eventually become as standard as tradictional Unix DAC, then yes, I would certainly have an expectation that most application developers would become aware of it eventually, just as they are aware of Unix DAC. I don't know what will happen, but I prefer the second option, so I would encourage people to become familiar with those issues. I think this is also the goal behind enabling targeted policy by default in Fedora - to make the technology more widespread, and useful to more people. Btw, I do have hopes that the Desktop will be confined in the future. I think technology in strict policy will mature, become more flexible, and be slowly integrated into targeted eventually, once it meets the requirements of Joe User (which it doesn't at this time). From jdesbonnet at gmail.com Fri Feb 24 13:41:23 2006 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Fri, 24 Feb 2006 13:41:23 +0000 Subject: RPM file name standard? Message-ID: <1cef3e950602240541i6e5ea59p75bdff43d05b5d2f@mail.gmail.com> Is there a document that defines the format of a RPM file name for the Fedora project? For example consider these RPMs: ImageMagick-perl-6.2.2.0-3.fc4.0.i386.rpm ImageMagick-perl-6.2.2.0-3.fc4.1.i386.rpm I'm puzzled about the significance of the numbers 0 and 1 following ".fc4." in these update RPMs. Thanks, Joe. From marcel at mesa.nl Fri Feb 24 13:47:46 2006 From: marcel at mesa.nl (Marcel J.E. Mol) Date: Fri, 24 Feb 2006 14:47:46 +0100 Subject: udev problems and starting KDE Message-ID: <20060224134746.GA9846@joshua.mesa.nl> Hello, Upgraded rawhide from a couple of weeksa go to rawhide of yesterday. When booting I get a load of udev messages: Starting udev: udevd-event[592]: wait_for_sysfs: waiting for '/sys/class/tty/ttyS0/bus' failed udevd-event[595]: wait_for_sysfs: waiting for '/sys/class/tty/ttyS3/bus' failed udevd-event[596]: wait_for_sysfs: waiting for '/sys/block/hda/bus' failed udevd-event[593]: wait_for_sysfs: waiting for '/sys/class/tty/ttyS1/bus' failed udevd-event[594]: wait_for_sysfs: waiting for '/sys/class/tty/ttyS2/bus' failed udevd-event[617]: wait_for_sysfs: waiting for '/sys/block/hdb/bus' failed udevd-event[691]: wait_for_sysfs: waiting for '/sys/class/graphics/fb0/bus' failed udevd-event[692]: wait_for_sysfs: waiting for '/sys/class/input/input0/event0/bus' failed udevd-event[694]: wait_for_sysfs: waiting for '/sys/class/input/input1/event1/bus' failed udevd-event[696]: wait_for_sysfs: waiting for '/sys/class/input/input1/mouse0/bus' failed udevd-event[736]: wait_for_sysfs: waiting for '/sys/class/pcmcia_socket/pcmcia_socket1/bus' failed udevd-event[748]: wait_for_sysfs: waiting for '/sys/class/input/input2/bus' failed udevd-event[810]: wait_for_sysfs: waiting for '/sys/class/net/eth0/bus' failed udevd-event[823]: wait_for_sysfs: waiting for '/sys/class/pcmcia_socket/pcmcia_socket0/bus' failed udevd-event[844]: wait_for_sysfs: waiting for '/sys/class/sound/pcmC0D0c/bus' failed udevd-event[843]: wait_for_sysfs: waiting for '/sys/class/sound/pcmC0D0p/bus' failed udevd-event[845]: wait_for_sysfs: waiting for '/sys/class/sound/dsp/bus' failed udevd-event[846]: wait_for_sysfs: waiting for '/sys/class/sound/audio/bus' failed udevd-event[855]: wait_for_sysfs: waiting for '/sys/class/ieee1394_host/fw-host0/bus' failed udevd-event[853]: wait_for_sysfs: waiting for '/sys/block/hde/bus' failed udevd-event[856]: wait_for_sysfs: waiting for '/sys/class/sound/controlC0/bus' failed udevd-event[857]: wait_for_sysfs: waiting for '/sys/class/sound/mixer/bus' failed udevd-event[881]: wait_for_sysfs: waiting for '/sys/block/hda/hda1/bus' failed udevd-event[882]: wait_for_sysfs: waiting for '/sys/block/hda/hda2/bus' failed udevd-event[883]: wait_for_sysfs: waiting for '/sys/block/hda/hda3/bus' failed udevd-event[885]: wait_for_sysfs: waiting for '/sys/block/hda/hda5/bus' failed udevd-event[886]: wait_for_sysfs: waiting for '/sys/block/hda/hda6/bus' failed udevd-event[887]: wait_for_sysfs: waiting for '/sys/block/hda/hda7/bus' failed udevd-event[888]: wait_for_sysfs: waiting for '/sys/block/hda/hda8/bus' failed udevd-event[884]: wait_for_sysfs: waiting for '/sys/block/hda/hda4/bus' failed udevd-event[895]: wait_for_sysfs: waiting for '/sys/class/ieee1394_node/364fc00015881410/bus' failed udevd-event[899]: wait_for_sysfs: waiting for '/sys/class/ieee1394/364fc00015881410-0/bus' failed udevd-event[936]: wait_for_sysfs: waiting for '/sys/class/input/input0/bus' failed udevd-event[931]: wait_for_sysfs: waiting for '/sys/class/input/input1/bus' failed udevd-event[947]: wait_for_sysfs: waiting for '/sys/class/input/input2/mouse1/bus' failed udevd-event[948]: wait_for_sysfs: waiting for '/sys/class/input/input2/event2/bus' failed udevd-event[995]: wait_for_sysfs: waiting for '/sys/block/hde/hde1/bus' failed udevd-event[1084]: wait_for_sysfs: waiting for '/sys/block/fd0/bus' failed When I kill udevd and run /sbin/start_udev again the messages are gone... I don't know if it is related but since the upgrade I cannot start kde or gnome anymore as a normal user. For kde I get: startkde: Starting up... DCOP aborting call from 'anonymous-776' to 'kded' startkde: Shutting down... klauncher: Exiting on signal 1 startkde: Running shutdown scripts... startkde: Done. Starting X and KDE as root works fine though! I reinstalled the whole kde set, and een went back to kde of FC5test3 (as suggested by older post having similar problems), but that does not help. Also removing the .kde tree does not help. It probably is some sort of permission problem but I don't have a clue where to look.... Any suggestions? Thanks -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 tla-ml at rasmil.dk Fri Feb 24 13:52:18 2006 From: tla-ml at rasmil.dk (Tim Lauridsen) Date: Fri, 24 Feb 2006 14:52:18 +0100 Subject: udev problems and starting KDE In-Reply-To: <20060224134746.GA9846@joshua.mesa.nl> References: <20060224134746.GA9846@joshua.mesa.nl> Message-ID: <43FF0F92.40107@rasmil.dk> Marcel J.E. Mol wrote: > Hello, > > Upgraded rawhide from a couple of weeksa go to rawhide of yesterday. > When booting I get a load of udev messages: > > Starting udev: udevd-event[592]: wait_for_sysfs: waiting for '/sys/class/tty/ttyS0/bus' failed > udevd-event[595]: wait_for_sysfs: waiting for '/sys/class/tty/ttyS3/bus' failed > udevd-event[596]: wait_for_sysfs: waiting for '/sys/block/hda/bus' failed > udevd-event[593]: wait_for_sysfs: waiting for '/sys/class/tty/ttyS1/bus' failed > udevd-event[594]: wait_for_sysfs: waiting for '/sys/class/tty/ttyS2/bus' failed > udevd-event[617]: wait_for_sysfs: waiting for '/sys/block/hdb/bus' failed > udevd-event[691]: wait_for_sysfs: waiting for '/sys/class/graphics/fb0/bus' failed > udevd-event[692]: wait_for_sysfs: waiting for '/sys/class/input/input0/event0/bus' failed > udevd-event[694]: wait_for_sysfs: waiting for '/sys/class/input/input1/event1/bus' failed > udevd-event[696]: wait_for_sysfs: waiting for '/sys/class/input/input1/mouse0/bus' failed > udevd-event[736]: wait_for_sysfs: waiting for '/sys/class/pcmcia_socket/pcmcia_socket1/bus' failed > udevd-event[748]: wait_for_sysfs: waiting for '/sys/class/input/input2/bus' failed > udevd-event[810]: wait_for_sysfs: waiting for '/sys/class/net/eth0/bus' failed > udevd-event[823]: wait_for_sysfs: waiting for '/sys/class/pcmcia_socket/pcmcia_socket0/bus' failed > udevd-event[844]: wait_for_sysfs: waiting for '/sys/class/sound/pcmC0D0c/bus' failed > udevd-event[843]: wait_for_sysfs: waiting for '/sys/class/sound/pcmC0D0p/bus' failed > udevd-event[845]: wait_for_sysfs: waiting for '/sys/class/sound/dsp/bus' failed > udevd-event[846]: wait_for_sysfs: waiting for '/sys/class/sound/audio/bus' failed > udevd-event[855]: wait_for_sysfs: waiting for '/sys/class/ieee1394_host/fw-host0/bus' failed > udevd-event[853]: wait_for_sysfs: waiting for '/sys/block/hde/bus' failed > udevd-event[856]: wait_for_sysfs: waiting for '/sys/class/sound/controlC0/bus' failed > udevd-event[857]: wait_for_sysfs: waiting for '/sys/class/sound/mixer/bus' failed > udevd-event[881]: wait_for_sysfs: waiting for '/sys/block/hda/hda1/bus' failed > udevd-event[882]: wait_for_sysfs: waiting for '/sys/block/hda/hda2/bus' failed > udevd-event[883]: wait_for_sysfs: waiting for '/sys/block/hda/hda3/bus' failed > udevd-event[885]: wait_for_sysfs: waiting for '/sys/block/hda/hda5/bus' failed > udevd-event[886]: wait_for_sysfs: waiting for '/sys/block/hda/hda6/bus' failed > udevd-event[887]: wait_for_sysfs: waiting for '/sys/block/hda/hda7/bus' failed > udevd-event[888]: wait_for_sysfs: waiting for '/sys/block/hda/hda8/bus' failed > udevd-event[884]: wait_for_sysfs: waiting for '/sys/block/hda/hda4/bus' failed > udevd-event[895]: wait_for_sysfs: waiting for '/sys/class/ieee1394_node/364fc00015881410/bus' failed > udevd-event[899]: wait_for_sysfs: waiting for '/sys/class/ieee1394/364fc00015881410-0/bus' failed > udevd-event[936]: wait_for_sysfs: waiting for '/sys/class/input/input0/bus' failed > udevd-event[931]: wait_for_sysfs: waiting for '/sys/class/input/input1/bus' failed > udevd-event[947]: wait_for_sysfs: waiting for '/sys/class/input/input2/mouse1/bus' failed > udevd-event[948]: wait_for_sysfs: waiting for '/sys/class/input/input2/event2/bus' failed > udevd-event[995]: wait_for_sysfs: waiting for '/sys/block/hde/hde1/bus' failed > udevd-event[1084]: wait_for_sysfs: waiting for '/sys/block/fd0/bus' failed > > > When I kill udevd and run /sbin/start_udev again the messages are gone... > > I don't know if it is related but since the upgrade I cannot start kde or gnome > anymore as a normal user. For kde I get: > > startkde: Starting up... > DCOP aborting call from 'anonymous-776' to 'kded' > startkde: Shutting down... > klauncher: Exiting on signal 1 > startkde: Running shutdown scripts... > startkde: Done. > > Starting X and KDE as root works fine though! > > I reinstalled the whole kde set, and een went back to kde of FC5test3 > (as suggested by older post having similar problems), but that does not > help. Also removing the .kde tree does not help. > It probably is some sort of permission problem but I don't have a clue > where to look.... > > Any suggestions? > > Thanks > > -Marcel > I had the same problem, i disabled selinux and everything was working again. Tim From emeric.maschino at jouy.inra.fr Fri Feb 24 13:59:36 2006 From: emeric.maschino at jouy.inra.fr (Emeric Maschino) Date: Fri, 24 Feb 2006 14:59:36 +0100 Subject: udev problems and starting KDE In-Reply-To: <20060224134746.GA9846@joshua.mesa.nl> References: <20060224134746.GA9846@joshua.mesa.nl> Message-ID: <1140789576.5088.46.camel@localhost.localdomain> Hi, > Hello, > > Upgraded rawhide from a couple of weeksa go to rawhide of yesterday. > When booting I get a load of udev messages: > > Starting udev: udevd-event[592]: wait_for_sysfs: waiting for '/sys/class/tty/ttyS0/bus' failed > udevd-event[595]: wait_for_sysfs: waiting for '/sys/class/tty/ttyS3/bus' failed > udevd-event[596]: wait_for_sysfs: waiting for '/sys/block/hda/bus' failed > udevd-event[593]: wait_for_sysfs: waiting for '/sys/class/tty/ttyS1/bus' failed Same problem here, however I can start GNOME without a problem. There was a similar problem on Debian a few days ago (at least on ia64 platform). The solution was to recreate the initrd image. However, this trick doesn't work for me with Rawhide ia64. ?meric From kwade at redhat.com Fri Feb 24 14:08:46 2006 From: kwade at redhat.com (Karsten Wade) Date: Fri, 24 Feb 2006 06:08:46 -0800 Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) In-Reply-To: <43FE1CB7.9080506@redhat.com> References: <43FD0AC0.2090702@redhat.com> <604aa7910602230634l5751103v11690aa4e241fcab@mail.gmail.com> <200602231019.28227.lamont@gurulabs.com> <20060223204634.21654c4f@dhcp05.addix.net> <43FE1CB7.9080506@redhat.com> Message-ID: <1140790126.8018.143.camel@erato.phig.org> On Thu, 2006-02-23 at 15:36 -0500, John Poelstra wrote: > Ralf Ertzinger wrote: > > Is there a decent book available on understanding and managing > > selinux (covering what is available in RHEL4)? I am quite fond > > of dead tree versions for learning about a topic, and printing > > out PDFs is unsatisfying. > > > > http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ Yes, that is the de facto standard for RHEL 4 SELinux information. If you are just looking to get stuff done, look in the second part of the book. Best yet, flip to the Index and look under "how to". For learning about SELinux, the "what is/what are" Index entries are numerous and useful. http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/generated-index.html For developers (hey, now I'm on-topic!), the first part that explains about SELinux and how it works is ... well, it is what it is. I did the best I could to make sense out of it for you all. ;-) I encourage you to give the PDF a try. I pored over it, page by page, to make sure that it prints out without content loss or nasty, ugly formatting. If you don't want to print it yourself, Cafepress or Kinkos is quite capable. http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/pdf/rhel-selg-en.pdf > http://www.amazon.com/gp/search/ref=br_ss_hs/103-0884455-3434219?search-alias=aps&keywords=selinux > The only one there remotely useful is the upcoming SELinux by Example [1], authored by people who know what they are talking about. Aug. 2006 is the publication date on Amazon. The ORA book was based on FC 2 and a waaaaaay older framework in the kernel. - Karsten [1] http://www.amazon.com/gp/product/0131963694/sr=8-6/qid=1140789393/ref=sr_1_6/103-8886514-7165421?%5Fencoding=UTF8 -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Fri Feb 24 14:17:21 2006 From: kwade at redhat.com (Karsten Wade) Date: Fri, 24 Feb 2006 06:17:21 -0800 Subject: Fwd: Stateless linux and an idea of mine for SMALL networks without servers In-Reply-To: References: Message-ID: <1140790641.8018.147.camel@erato.phig.org> On Thu, 2006-02-23 at 10:09 -0600, Nic wrote: > (I had been trying to send this email without much success. Sorry if > you got it twice) > > I hope that this is the right mailing list, but I really wanted to > reach developers would can say if it's feasible and what to use for > that. Not sure if this is or is not on-topic, but it's worth at least one answer to the security issue. The rest is technically feasible using rsync and some automation. > Additionally, every login ALSO uses a dongle/card for access to their > account. This makes it (almost) impossible for somebody stealing a > laptop to get access to the whole data. Stolen or lost laptops are a real concern. If someone has physical access to the hard drive, the determination, and sufficient resources, it is only a matter of time until they get the data off it. - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From brads at redhat.com Fri Feb 24 14:20:12 2006 From: brads at redhat.com (Brad Smith) Date: Fri, 24 Feb 2006 09:20:12 -0500 Subject: Virtual machine software for Fedora testing? In-Reply-To: <43FE28A2.20906@cygnusx-1.org> References: <1cef3e950602231322u3c43f267k1a08290cf8755c47@mail.gmail.com> <43FE28A2.20906@cygnusx-1.org> Message-ID: <43FF161C.8030805@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Among the suggestions provided for VMs in Fedora: qemu, xen, vmware and linux-vserver, is there any clear preference in terms of ease of use and integration into the distro? Since xen is the only one that is actually part of Fedora I'd like to assume that there's some quantitative advantage to it over the alternatives. Is this not the case? I guess my question could be rephrased: If xen comes with Fedora is there a reason for someone who wants to run virtual test systems in Fedora to use anything else? - --Brad -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFD/xYcDvp49DvQ8kcRAvH5AJwIXxu5FBk8GoqWscal2GR69ycxEgCeMHB4 wMuQHCVNWg8VRY7wCnAz/wA= =O8J9 -----END PGP SIGNATURE----- From marcel at mesa.nl Fri Feb 24 14:23:01 2006 From: marcel at mesa.nl (Marcel J.E. Mol) Date: Fri, 24 Feb 2006 15:23:01 +0100 Subject: udev problems and starting KDE In-Reply-To: <43FF0F92.40107@rasmil.dk> References: <20060224134746.GA9846@joshua.mesa.nl> <43FF0F92.40107@rasmil.dk> Message-ID: <20060224142301.GC9846@joshua.mesa.nl> On Fri, Feb 24, 2006 at 02:52:18PM +0100, Tim Lauridsen wrote: > Marcel J.E. Mol wrote: > >Hello, > > > >Upgraded rawhide from a couple of weeksa go to rawhide of yesterday. > >When booting I get a load of udev messages: > > > > Starting udev: udevd-event[592]: wait_for_sysfs: waiting for > > ... > > udevd-event[1084]: wait_for_sysfs: waiting for '/sys/block/fd0/bus' > > failed > > > > > >When I kill udevd and run /sbin/start_udev again the messages are gone... > > > >I don't know if it is related but since the upgrade I cannot start kde or > >gnome > >anymore as a normal user. For kde I get: > > > > startkde: Starting up... > > DCOP aborting call from 'anonymous-776' to 'kded' > > startkde: Shutting down... > > klauncher: Exiting on signal 1 > > startkde: Running shutdown scripts... > > startkde: Done. > > > >Starting X and KDE as root works fine though! > > > >I reinstalled the whole kde set, and een went back to kde of FC5test3 > >(as suggested by older post having similar problems), but that does not > >help. Also removing the .kde tree does not help. > >It probably is some sort of permission problem but I don't have a clue > >where to look.... > > > >Any suggestions? > > > >Thanks > > > >-Marcel > > > I had the same problem, i disabled selinux and everything was working again. Selinux has always been disabled on this system and still is. So that is not the problem here... -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 dennis at ausil.us Fri Feb 24 14:26:26 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 24 Feb 2006 08:26:26 -0600 Subject: udev problems and starting KDE In-Reply-To: <1140789576.5088.46.camel@localhost.localdomain> References: <20060224134746.GA9846@joshua.mesa.nl> <1140789576.5088.46.camel@localhost.localdomain> Message-ID: <200602240826.26957.dennis@ausil.us> On Friday 24 February 2006 07:59, Emeric Maschino wrote: > Hi, > Same problem here, however I can start GNOME without a problem. > > There was a similar problem on Debian a few days ago (at least on ia64 > platform). The solution was to recreate the initrd image. However, this > trick doesn't work for me with Rawhide ia64. your running on an itanium? i guess thats what ia64 is or do you mean x86_64 ? -- Regards Dennis Gilmore, RHCE Proud Australian From harald at redhat.com Fri Feb 24 14:27:18 2006 From: harald at redhat.com (Harald Hoyer) Date: Fri, 24 Feb 2006 15:27:18 +0100 Subject: udev problems and starting KDE In-Reply-To: <20060224134746.GA9846@joshua.mesa.nl> References: <20060224134746.GA9846@joshua.mesa.nl> Message-ID: <43FF17C6.50107@redhat.com> Marcel J.E. Mol wrote: > Hello, > > Upgraded rawhide from a couple of weeksa go to rawhide of yesterday. > When booting I get a load of udev messages: > > Starting udev: udevd-event[592]: wait_for_sysfs: waiting for '/sys/class/tty/ttyS0/bus' failed > udevd-event[595]: wait_for_sysfs: waiting for '/sys/class/tty/ttyS3/bus' failed > udevd-event[596]: wait_for_sysfs: waiting for '/sys/block/hda/bus' failed > udevd-event[593]: wait_for_sysfs: waiting for '/sys/class/tty/ttyS1/bus' failed > udevd-event[594]: wait_for_sysfs: waiting for '/sys/class/tty/ttyS2/bus' failed > udevd-event[617]: wait_for_sysfs: waiting for '/sys/block/hdb/bus' failed > udevd-event[691]: wait_for_sysfs: waiting for '/sys/class/graphics/fb0/bus' failed > udevd-event[692]: wait_for_sysfs: waiting for '/sys/class/input/input0/event0/bus' failed > udevd-event[694]: wait_for_sysfs: waiting for '/sys/class/input/input1/event1/bus' failed > udevd-event[696]: wait_for_sysfs: waiting for '/sys/class/input/input1/mouse0/bus' failed > udevd-event[736]: wait_for_sysfs: waiting for '/sys/class/pcmcia_socket/pcmcia_socket1/bus' failed > udevd-event[748]: wait_for_sysfs: waiting for '/sys/class/input/input2/bus' failed > udevd-event[810]: wait_for_sysfs: waiting for '/sys/class/net/eth0/bus' failed > udevd-event[823]: wait_for_sysfs: waiting for '/sys/class/pcmcia_socket/pcmcia_socket0/bus' failed > udevd-event[844]: wait_for_sysfs: waiting for '/sys/class/sound/pcmC0D0c/bus' failed > udevd-event[843]: wait_for_sysfs: waiting for '/sys/class/sound/pcmC0D0p/bus' failed > udevd-event[845]: wait_for_sysfs: waiting for '/sys/class/sound/dsp/bus' failed > udevd-event[846]: wait_for_sysfs: waiting for '/sys/class/sound/audio/bus' failed > udevd-event[855]: wait_for_sysfs: waiting for '/sys/class/ieee1394_host/fw-host0/bus' failed > udevd-event[853]: wait_for_sysfs: waiting for '/sys/block/hde/bus' failed > udevd-event[856]: wait_for_sysfs: waiting for '/sys/class/sound/controlC0/bus' failed > udevd-event[857]: wait_for_sysfs: waiting for '/sys/class/sound/mixer/bus' failed > udevd-event[881]: wait_for_sysfs: waiting for '/sys/block/hda/hda1/bus' failed > udevd-event[882]: wait_for_sysfs: waiting for '/sys/block/hda/hda2/bus' failed > udevd-event[883]: wait_for_sysfs: waiting for '/sys/block/hda/hda3/bus' failed > udevd-event[885]: wait_for_sysfs: waiting for '/sys/block/hda/hda5/bus' failed > udevd-event[886]: wait_for_sysfs: waiting for '/sys/block/hda/hda6/bus' failed > udevd-event[887]: wait_for_sysfs: waiting for '/sys/block/hda/hda7/bus' failed > udevd-event[888]: wait_for_sysfs: waiting for '/sys/block/hda/hda8/bus' failed > udevd-event[884]: wait_for_sysfs: waiting for '/sys/block/hda/hda4/bus' failed > udevd-event[895]: wait_for_sysfs: waiting for '/sys/class/ieee1394_node/364fc00015881410/bus' failed > udevd-event[899]: wait_for_sysfs: waiting for '/sys/class/ieee1394/364fc00015881410-0/bus' failed > udevd-event[936]: wait_for_sysfs: waiting for '/sys/class/input/input0/bus' failed > udevd-event[931]: wait_for_sysfs: waiting for '/sys/class/input/input1/bus' failed > udevd-event[947]: wait_for_sysfs: waiting for '/sys/class/input/input2/mouse1/bus' failed > udevd-event[948]: wait_for_sysfs: waiting for '/sys/class/input/input2/event2/bus' failed > udevd-event[995]: wait_for_sysfs: waiting for '/sys/block/hde/hde1/bus' failed > udevd-event[1084]: wait_for_sysfs: waiting for '/sys/block/fd0/bus' failed > Try to remove the line with WAIT_FOR_SYSFS="bus" in /etc/udev/rules.d/05-udev-early.rules and restart. From gajownik at fedora.pl Fri Feb 24 14:35:45 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Fri, 24 Feb 2006 15:35:45 +0100 Subject: Low OpenGL performance In-Reply-To: <36006.194.94.224.254.1140611334.squirrel@jose.freesurf.fr> References: <36006.194.94.224.254.1140611334.squirrel@jose.freesurf.fr> Message-ID: <43FF19C1.4000008@fedora.pl> Dnia 02/22/2006 01:31 PM, U?ytkownik Joachim Frieben napisa?: > After installing FC5T3 including updates on 2 different machines, I am > puzzled by the surprisingly poor OpenGL performance when running the > "glxgears" command Mesa does not enable compiler optimisations by default: http://cvs.freedesktop.org/mesa/Mesa/configs/linux-dri (see the log next to the 1.12 revision) http://sourceforge.net/mailarchive/forum.php?thread_id=5432450&forum_id=5154 I spotted this when I was testing modular X.Org X11 in September 2005. I also wrote an email about it to Mike A. Harris , but I did not get an answer ;) Mesa seems to be built with `-Wall -O -g' flags. You may want to download srpm and modify configs/default/linux-dri file. Changing OPT_FLAGS variable to the output of `rpm --eval %{optflags}' command may resolve your problem. Unfortunately, I cannot test it because I have nVidia crap and nv driver does not support 3D acceleration [1]. Hopefully, I'll swith soon to ATI RADEON 8500 :) [1] It would be great if someone could port BeOS driver to X.Org X11 http://haikunews.org/1050 https://bugs.freedesktop.org/show_bug.cgi?id=5190#c5 -- ^_* From che666 at gmail.com Fri Feb 24 14:39:16 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Fri, 24 Feb 2006 15:39:16 +0100 Subject: where to report xair problems? bugzilla component going to be added? Message-ID: Hello! wouldnt it help to have a bugzilla entry somewhere for xair problems and bugs? the component is yet missing while xair is going to get shipped with fc5 according to the news ;) just curious really because i couldnt find the component for fc development. Also not sure if it makes sense at all at this point. regards, rudolf kastl From che666 at gmail.com Fri Feb 24 14:41:17 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Fri, 24 Feb 2006 15:41:17 +0100 Subject: Low OpenGL performance In-Reply-To: <43FF19C1.4000008@fedora.pl> References: <36006.194.94.224.254.1140611334.squirrel@jose.freesurf.fr> <43FF19C1.4000008@fedora.pl> Message-ID: 2006/2/24, Dawid Gajownik : > Dnia 02/22/2006 01:31 PM, U?ytkownik Joachim Frieben napisa?: > > After installing FC5T3 including updates on 2 different machines, I am > > puzzled by the surprisingly poor OpenGL performance when running the > > "glxgears" command > > Mesa does not enable compiler optimisations by default: > http://cvs.freedesktop.org/mesa/Mesa/configs/linux-dri (see the log next > to the 1.12 revision) > http://sourceforge.net/mailarchive/forum.php?thread_id=5432450&forum_id=5154 > > I spotted this when I was testing modular X.Org X11 in September 2005. I > also wrote an email about it to Mike A. Harris , but I did not get an > answer ;) > > Mesa seems to be built with `-Wall -O -g' flags. You may want to > download srpm and modify configs/default/linux-dri file. Changing > OPT_FLAGS variable to the output of `rpm --eval %{optflags}' command may > resolve your problem. > > Unfortunately, I cannot test it because I have nVidia crap and nv driver > does not support 3D acceleration [1]. Hopefully, I'll swith soon to ATI > RADEON 8500 :) > > [1] It would be great if someone could port BeOS driver to X.Org X11 > http://haikunews.org/1050 > https://bugs.freedesktop.org/show_bug.cgi?id=5190#c5 > > -- > > ^_* > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > hacking the flags in statically to the file isnt a proper solution. there must be a way to do that with a variable etc... i am going to look into the stuff this evening and will report back to that thread once i have sent a patch to bugzilla. regards, rudolf kastl From nigel.metheringham at dev.intechnology.co.uk Fri Feb 24 14:43:31 2006 From: nigel.metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Fri, 24 Feb 2006 14:43:31 +0000 Subject: Virtual machine software for Fedora testing? In-Reply-To: <43FF161C.8030805@redhat.com> References: <1cef3e950602231322u3c43f267k1a08290cf8755c47@mail.gmail.com> <43FE28A2.20906@cygnusx-1.org> <43FF161C.8030805@redhat.com> Message-ID: <1140792211.21535.32.camel@localhost.localdomain> On Fri, 2006-02-24 at 09:20 -0500, Brad Smith wrote: > I guess my question could be rephrased: If xen comes with Fedora is > there a reason for someone who wants to run virtual test systems in > Fedora to use anything else? Xen is a para-virtualisation system - the virtualised system/os needs to built in a way that is appropriate for virtualising. This means that you are (currently) unable to use xen for running windows images or even installing older (non xen aware) versions of Linux. Since Xen requires support at kernel level it really needs to be in core if its supported (and it is both in core and supported). Qemu is a more complete or maybe more traditional virtualisation setup - it effectively emulates the hardware of a standard system. However its rather slower than Xen. You can also emulate an entirely different architecture under qemu (I have installed a x86_64 fedora on a i386 under qemu - but it was glacially slow). There is a non-free kernel module that speeds up emulation of i386 on i386. Qemu can also be used to run binaries for one system on another without emulating the complete system - in a way vaguely analogous to what wine does. VMware is effectively a commercial, shinier, faster version of qemu (VMware would dispute this - they were there way before qemu). Its much easier to manage and probably better on some cases where the qemu emulated hardware is insufficient. Its obviously not a candidate for Fedora even in its new free (gratis) form. There is also a big brother - ESX - which runs virtual machines over an ESX kernel running on bare metal, which is used for virtualising services. I don't think VMware does anything other than i386 running on i386 (unlike qemu). Qemu would be a good extras candidate. I'm a bit surprised to see its not in extras at present. Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From bruno at wolff.to Fri Feb 24 15:08:27 2006 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 24 Feb 2006 09:08:27 -0600 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <43FEDE89.5050301@mharris.ca> References: <43FD0AC0.2090702@redhat.com> <43FD78EC.4080104@3di.it> <43FEDE89.5050301@mharris.ca> Message-ID: <20060224150827.GB25256@wolff.to> On Fri, Feb 24, 2006 at 05:23:05 -0500, "Mike A. Harris" wrote: > Davide Bolcioni wrote: > >Mike A. Harris wrote: > > > >>Both ATI and Nvidia's proprietary video driver installation utilities > >>replace the Red Hat supplied libGL library with their own libGL. > > > > > >Could SELinux be used to prevent this and, more generally, disallow > >replacement of rpm-controlled files even by the root user ? Yes it should be possible to do this. However, you need some way to distinguish updates of those libraries when done normally as opposed to being done by ATI or Nvidia code. What you would probably like to do is only let rpm change those files. However if ATI and Nvidia are supplying rpms, selinux isn't going to be able to tell the difference. You could also go by what role the person who runs rpm had. Then it would be up to you to change your role based on whose rpms you were installing. Another issue is that files only have one tag for selinux and if you use a tag that indicates just that it was installed by rpm, that isn't going to play nice with other selinux policies. You might be able to get away with restricting how files with a number of different types are updated. You may cover some files you don't want doing this, but I think you could get close. Another approach would be to have rpm not allow rpms to stomp on files from other rpms if they weren't signed by the same key (perhaps --force would override that). From rdieter at math.unl.edu Fri Feb 24 15:03:12 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 24 Feb 2006 09:03:12 -0600 Subject: RPM file name standard? In-Reply-To: <1cef3e950602240541i6e5ea59p75bdff43d05b5d2f@mail.gmail.com> References: <1cef3e950602240541i6e5ea59p75bdff43d05b5d2f@mail.gmail.com> Message-ID: Joe Desbonnet wrote: > Is there a document that defines the format of a RPM file name for the > Fedora project? Fedora Core? No. Fedora Extras? Yes: http://fedoraproject.org/wiki/Packaging/Guidelines http://fedoraproject.org/wiki/Packaging/NamingGuidelines -- Rex From ivazquez at ivazquez.net Fri Feb 24 15:06:14 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 24 Feb 2006 10:06:14 -0500 Subject: Virtual machine software for Fedora testing? In-Reply-To: <1140792211.21535.32.camel@localhost.localdomain> References: <1cef3e950602231322u3c43f267k1a08290cf8755c47@mail.gmail.com> <43FE28A2.20906@cygnusx-1.org> <43FF161C.8030805@redhat.com> <1140792211.21535.32.camel@localhost.localdomain> Message-ID: <1140793574.27580.1.camel@ignacio.lan> On Fri, 2006-02-24 at 14:43 +0000, Nigel Metheringham wrote: > I don't think VMware > does anything other than i386 running on i386 (unlike qemu). It can also do x86_64 running on x86_64, even if you're running a 32-bit OS. It can also do limited SMP. > Qemu would be a good extras candidate. I'm a bit surprised to see its > not in extras at present. It doesn't build against gcc4. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From brads at redhat.com Fri Feb 24 15:08:21 2006 From: brads at redhat.com (Brad Smith) Date: Fri, 24 Feb 2006 10:08:21 -0500 Subject: RPM file name standard? In-Reply-To: <1cef3e950602240541i6e5ea59p75bdff43d05b5d2f@mail.gmail.com> References: <1cef3e950602240541i6e5ea59p75bdff43d05b5d2f@mail.gmail.com> Message-ID: <43FF2165.3090702@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joe Desbonnet wrote: > Is there a document that defines the format of a RPM file name for the > Fedora project? > > For example consider these RPMs: > ImageMagick-perl-6.2.2.0-3.fc4.0.i386.rpm > ImageMagick-perl-6.2.2.0-3.fc4.1.i386.rpm > I believe those may be Epoch numbers. See: http://www.rpm.org/max-rpm-snapshot/s1-rpm-inside-tags.html#S3-RPM-INSIDE-EPOCH-TAG - --Brad -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFD/yFkDvp49DvQ8kcRAiMpAJ4ywxF8N7+CseIGNCiSfMWfpYvIpgCfQ9mv Wacw0HBV140A6fdRE8QrWhs= =oRbr -----END PGP SIGNATURE----- From bruno at wolff.to Fri Feb 24 15:20:53 2006 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 24 Feb 2006 09:20:53 -0600 Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) In-Reply-To: <20060224124517.0fd0686e@dhcp05.addix.net> References: <200602240944.k1O9ixln016849@tiffany.internal.tigress.co.uk> <20060224124517.0fd0686e@dhcp05.addix.net> Message-ID: <20060224152053.GC25256@wolff.to> On Fri, Feb 24, 2006 at 12:45:17 +0100, Ralf Ertzinger wrote: > Hi. > > On Fri, 24 Feb 2006 06:42:45 -0500, Benjy Grogan wrote: > > > That was my understanding of SELinux. You could run a crazy program > > that has root privileges, is hackable, has no SELinux policy, and all > > that effort was for nigh. > > I think this is a question of policy. The "targeted" policy does > what you describe, it just confines specific applications. You are > free to use the reverse approach, though. And 'targetted' still buys you a lot. Not all programs are used the same way and some will be a lot more likely to be a way in to your system then others. For 'targetted', internet facing daemons have had restrictive policies written for them. These are one set of high risk programs. Another set, that I don't believe has gotten much coverage, are end users programs used to view data that typically comes from outside sources. This should include such things as web browsers, mail clients, editors, pdf viewers, and music and/or video players. From emeric.maschino at jouy.inra.fr Fri Feb 24 15:05:18 2006 From: emeric.maschino at jouy.inra.fr (Emeric Maschino) Date: Fri, 24 Feb 2006 16:05:18 +0100 Subject: udev problems and starting KDE In-Reply-To: <200602240826.26957.dennis@ausil.us> References: <20060224134746.GA9846@joshua.mesa.nl> <1140789576.5088.46.camel@localhost.localdomain> <200602240826.26957.dennis@ausil.us> Message-ID: <1140793518.5088.67.camel@localhost.localdomain> > > There was a similar problem on Debian a few days ago (at least on ia64 > > platform). The solution was to recreate the initrd image. However, this > > trick doesn't work for me with Rawhide ia64. > > your running on an itanium? i guess thats what ia64 is > > or do you mean x86_64 ? No, I really mean ia64 and you're correct, ia64 is for Itanium. Indeed, I'm running Rawhide on a hp workstation zx6000. ?meric From pknirsch at redhat.com Fri Feb 24 15:15:20 2006 From: pknirsch at redhat.com (Phil Knirsch) Date: Fri, 24 Feb 2006 16:15:20 +0100 Subject: Results for install and remove tests for FC-Devel In-Reply-To: <43FDA809.8060708@redhat.com> References: <43FC3ECA.9020100@redhat.com> <20060222171227.GE5568@devserv.devel.redhat.com> <43FDA809.8060708@redhat.com> Message-ID: <43FF2308.8000700@redhat.com> Phil Knirsch wrote: > Bill Nottingham wrote: > >> Phil Knirsch (pknirsch at redhat.com) said: >> >>> As i've written last Friday, i have been running a complete install >>> and removal test for all packages of the Friday snapshot of FC-Devel. >> >> >> Is it possible to get this filtered into bugzilla without a herculean >> amount of manual effort? >> >> Bill >> > > Sure, will do it today, Bill. > > Read ya, Phil > OK, took a day longer but all errors are now in bugzilla as well. 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 Kaa's Law: In any sufficiently large group of people most are idiots. From selinux at gmail.com Fri Feb 24 15:16:33 2006 From: selinux at gmail.com (Tom London) Date: Fri, 24 Feb 2006 07:16:33 -0800 Subject: udev problems and starting KDE In-Reply-To: <43FF17C6.50107@redhat.com> References: <20060224134746.GA9846@joshua.mesa.nl> <43FF17C6.50107@redhat.com> Message-ID: <4c4ba1530602240716xa5accd5ra794c13165193627@mail.gmail.com> On 2/24/06, Harald Hoyer wrote: > Try to remove the line with WAIT_FOR_SYSFS="bus" in /etc/udev/rules.d/05-udev-early.rules and restart. > Thanks, this WFM. tom -- Tom London From ifoox at redhat.com Fri Feb 24 15:25:33 2006 From: ifoox at redhat.com (Igor Foox) Date: Fri, 24 Feb 2006 10:25:33 -0500 Subject: eclipse In-Reply-To: <43FE2298.9030703@insitesinc.com> References: <1140712986.24563.15.camel@xpc.home.erwinrol.com> <43FDF670.7060700@insitesinc.com> <43FE2298.9030703@insitesinc.com> Message-ID: <1140794733.7675.2.camel@tool.toronto.redhat.com> On Thu, 2006-02-23 at 15:01 -0600, Michael Favia wrote: > Michael Favia wrote: > > Will install this afternoon and report back with troubles if > > any. -mf > Had a chance to install this afternoon. Is this really still necessary > (please see dependency resolution report from yum on bottom of msg)? > Some of those make sense to me but tomcat? I seem to remember something > about this issue before but don't remember what in particular it was. Hi Michael, Eclipse uses tomcat for the help system, this is true of the upstream Eclipse as well as the one shipped on Fedora. Eclipse starts a tomcat server when you first open up the help, which is why there's a slight delay the first time you do it, which serves the html pages of the help system. Unfortunately there's not much we can do to get around this. :) > ============================================================================= > Package Arch Version Repository Size > ============================================================================= > Installing: > eclipse-platform i386 1:3.1.2-1jpp_7fc development > 53 M > Installing for dependencies: > ant-apache-bsf i386 1.6.5-1jpp_6fc development > 44 k > ant-javamail i386 1.6.5-1jpp_6fc development > 34 k > eclipse-rcp i386 1:3.1.2-1jpp_7fc development > 46 k > geronimo-specs i386 1.0-0.M2.2jpp_7fc development > 227 k > geronimo-specs-compat i386 1.0-0.M2.2jpp_7fc development > 4.9 k > jakarta-commons-fileupload noarch 1:1.0-3jpp_4fc development > 24 k > java-1.4.2-gcj-compat-javadoc i386 1.4.2.0-40jpp_80rh > development 21 M > lucene i386 1.4.3-1jpp_11fc development > 660 k > lucene-demo i386 1.4.3-1jpp_11fc development > 104 k > tomcat5 i386 5.0.30-8jpp_11fc development > 3.6 M > tomcat5-jasper i386 5.0.30-8jpp_11fc development > 878 k > > Transaction Summary > ============================================================================= > Install 12 Package(s) > Update 0 Package(s) > Remove 0 Package(s) > Total download size: 80 M From mharris at mharris.ca Fri Feb 24 15:25:00 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Fri, 24 Feb 2006 10:25:00 -0500 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <20060224150827.GB25256@wolff.to> References: <43FD0AC0.2090702@redhat.com> <43FD78EC.4080104@3di.it> <43FEDE89.5050301@mharris.ca> <20060224150827.GB25256@wolff.to> Message-ID: <43FF254C.2020705@mharris.ca> Bruno Wolff III wrote: > On Fri, Feb 24, 2006 at 05:23:05 -0500, > "Mike A. Harris" wrote: > >>Davide Bolcioni wrote: >> >>>Mike A. Harris wrote: >>> >>> >>>>Both ATI and Nvidia's proprietary video driver installation utilities >>>>replace the Red Hat supplied libGL library with their own libGL. >>> >>> >>>Could SELinux be used to prevent this and, more generally, disallow >>>replacement of rpm-controlled files even by the root user ? > > > Yes it should be possible to do this. However, you need some way to distinguish > updates of those libraries when done normally as opposed to being done by > ATI or Nvidia code. What you would probably like to do is only let rpm > change those files. However if ATI and Nvidia are supplying rpms, selinux > isn't going to be able to tell the difference. > > You could also go by what role the person who runs rpm had. Then it would be > up to you to change your role based on whose rpms you were installing. > > Another issue is that files only have one tag for selinux and if you use > a tag that indicates just that it was installed by rpm, that isn't going to > play nice with other selinux policies. You might be able to get away with > restricting how files with a number of different types are updated. You > may cover some files you don't want doing this, but I think you could get > close. > > Another approach would be to have rpm not allow rpms to stomp on files > from other rpms if they weren't signed by the same key (perhaps --force > would override that). Except: 1) It would be an ugly hack, and would not actually stop people from doing what they really want to anyway. 2) Would make people get upset at SElinux and probably disable it if they don't already. 3) Would probably result in FAQ's and other "advice" to fix the problem recommending disabling SElinux. 4) Would require significant additional work to implement and test. 5) Even if it was implemented, many people already do not use SElinux, and would thus not be affected by the changes anyway. 6) Would not really bring any real world gain in the end. I can't really envision anyone coming up with any viable rationale to really consider this as an option. Everyone is given an OS to install and use, and with that freedom comes responsibility. You're given the rope to hang yourself with in thousands of places in Linux and Linux-like OSs. It is entirely the responsibility of the system administrator, or user responsible for the computer system to ensure that they are installing software wisely. However, it is always possible to hang one's self with the rope one is given. Trying to make the OS prevent all possible manners in which a user can hang themselves is simply not possible, fruitless to waste time on, and generally speaking, is more likely to cause more problems than it solves. idea.veto = 1; -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From ivg2 at cornell.edu Fri Feb 24 15:27:37 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 24 Feb 2006 10:27:37 -0500 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <20060224150827.GB25256@wolff.to> References: <43FD0AC0.2090702@redhat.com> <43FD78EC.4080104@3di.it> <43FEDE89.5050301@mharris.ca> <20060224150827.GB25256@wolff.to> Message-ID: <43FF25E9.1080802@cornell.edu> >>>> Both ATI and Nvidia's proprietary video driver installation utilities >>>> replace the Red Hat supplied libGL library with their own libGL. >>>> >>> Could SELinux be used to prevent this and, more generally, disallow >>> replacement of rpm-controlled files even by the root user ? >>> > > Yes it should be possible to do this. However, you need some way to distinguish > updates of those libraries when done normally as opposed to being done by > ATI or Nvidia code. What you would probably like to do is only let rpm > change those files. However if ATI and Nvidia are supplying rpms, selinux > isn't going to be able to tell the difference. > The goal here is not to prevent Nvidia-supplied rpms to run on Linux. The goal is to prevent shell-based installers from modifying files that are "controlled" by the rpm database. Nvidia rpms would not create a problem on Fedora, since any conflicts with other rpms would be exposed by the package manager. > Another issue is that files only have one tag for selinux and if you use > a tag that indicates just that it was installed by rpm, that isn't going to > play nice with other selinux policies. You might be able to get away with > restricting how files with a number of different types are updated. You > may cover some files you don't want doing this, but I think you could get > close. > I think this is the correct way to do it. I don't follow why you couldn't get close... You'd enumerate all the contexts for files under /lib, /usr/lib, etc.. places which would be declared "controlled" by rpm. Then you create a new attribute called "managed" or something like that, and mark all those types with that attribute. Then you write policy to allow rpm to manage those types. You write an assertion to make sure nothing but rpm manages those files. Then audit and remove all rules from policy that violate that assertion. I haven't written policy in a while, but shouldn't this work? > Another approach would be to have rpm not allow rpms to stomp on files > from other rpms if they weren't signed by the same key (perhaps --force > would override that). > That solves a completely different problem from the original question. From veillard at redhat.com Fri Feb 24 15:31:45 2006 From: veillard at redhat.com (Daniel Veillard) Date: Fri, 24 Feb 2006 10:31:45 -0500 Subject: Virtual machine software for Fedora testing? In-Reply-To: <1140793574.27580.1.camel@ignacio.lan> References: <1cef3e950602231322u3c43f267k1a08290cf8755c47@mail.gmail.com> <43FE28A2.20906@cygnusx-1.org> <43FF161C.8030805@redhat.com> <1140792211.21535.32.camel@localhost.localdomain> <1140793574.27580.1.camel@ignacio.lan> Message-ID: <20060224153145.GY9506@redhat.com> On Fri, Feb 24, 2006 at 10:06:14AM -0500, Ignacio Vazquez-Abrams wrote: > On Fri, 2006-02-24 at 14:43 +0000, Nigel Metheringham wrote: > > I don't think VMware > > does anything other than i386 running on i386 (unlike qemu). > > It can also do x86_64 running on x86_64, even if you're running a 32-bit > OS. It can also do limited SMP. > > > Qemu would be a good extras candidate. I'm a bit surprised to see its > > not in extras at present. > > It doesn't build against gcc4. Well technically it builds, but you get somewhat erratic runtime results :-) Daniel -- Daniel Veillard | Red Hat 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 ivg2 at cornell.edu Fri Feb 24 15:32:11 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 24 Feb 2006 10:32:11 -0500 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <43FF25E9.1080802@cornell.edu> References: <43FD0AC0.2090702@redhat.com> <43FD78EC.4080104@3di.it> <43FEDE89.5050301@mharris.ca> <20060224150827.GB25256@wolff.to> <43FF25E9.1080802@cornell.edu> Message-ID: <43FF26FB.7000805@cornell.edu> > The goal here is not to prevent Nvidia-supplied rpms to run on Linux. > The goal is to prevent shell-based installers from modifying files > that are "controlled" by the rpm database. > Nvidia rpms would not create a problem on Fedora, since any conflicts > with other rpms would be exposed by the package manager. Well, maybe this is wishful thinking, since rpm does have scripting capabilities, so it can do whatever it wants to... From jspaleta at gmail.com Fri Feb 24 15:36:43 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 24 Feb 2006 10:36:43 -0500 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <43FF25E9.1080802@cornell.edu> References: <43FD0AC0.2090702@redhat.com> <43FD78EC.4080104@3di.it> <43FEDE89.5050301@mharris.ca> <20060224150827.GB25256@wolff.to> <43FF25E9.1080802@cornell.edu> Message-ID: <604aa7910602240736pd56fc20i50991a38038b9300@mail.gmail.com> On 2/24/06, Ivan Gyurdiev wrote: > The goal here is not to prevent Nvidia-supplied rpms to run on Linux. > The goal is to prevent shell-based installers from modifying files that > are "controlled" by the rpm database. > Nvidia rpms would not create a problem on Fedora, since any conflicts > with other rpms would be exposed by the package manager. Correction.. non-crackrock rpms would not create a problem. You can do an amazing amount of damage via postinstall scripts inside packages. It wouldn't be all that difficult to create an nvidia rpm that dropped the nvidia installer on the system and then ran the installer via postinstall script. In fact I'm pretty sure I've seen that sort of beast in the wild at some point. If your security is so tight that postinstall actions during rpm packages would generally fail when tampering with other package's files.. then you break lots of postinstall actions. -jef From mharris at redhat.com Fri Feb 24 15:42:02 2006 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 24 Feb 2006 10:42:02 -0500 Subject: REQUEST FOR TESTERS: xorg-x11-fonts-7.0-2 Message-ID: <43FF294A.9080800@redhat.com> I've built new xorg-x11-fonts packages to attempt to resolve bug #173875. The new packages seem to resolve the issue fine for me with local testing. However, since this changes the encodings.dir files which all invocations of mkfontdir and mkfontscale use, it is possible that these changes at least theoretically could change the way that fonts.dir files get generated. It is thus theoretically possible that people's fonts could disappear, or that some other unexpected results could occur after updating to the new font packages. As such, since FC5 is very close, in line with keeping risks to a minimum this late in the cycle, I want to get as many people as possible to upgrade to the new font packages and provide feedback before I consider putting them into rawhide. Please download the following font rpms, and upgrade to all of them with "rpm -Uvh *.rpm" and report back any error messages that occur, or any problems that occur after upgrading to the new packages. Please reboot your system so that xfs, the X server, and whatnot are all completely restarted to maximize the testing benefit. Additionally, I have put a diff of the spec file changes I've made in a file attachment in the bug. Peer review of the changes are also appreciated. The idea here is to try to avoid last minute catastrophes from entering the fray. Your help in testing this is greatly appreciated. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173875 Thanks in advance. -- Mike A. Harris, Systems Engineer, X11 Development team, Red Hat Canada, Ltd. From mharris at redhat.com Fri Feb 24 15:43:07 2006 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 24 Feb 2006 10:43:07 -0500 Subject: REQUEST FOR TESTERS: xorg-x11-fonts-7.0-2 Message-ID: <43FF298B.5020805@redhat.com> I've built new xorg-x11-fonts packages to attempt to resolve bug #173875. The new packages seem to resolve the issue fine for me with local testing. However, since this changes the encodings.dir files which all invocations of mkfontdir and mkfontscale use, it is possible that these changes at least theoretically could change the way that fonts.dir files get generated. It is thus theoretically possible that people's fonts could disappear, or that some other unexpected results could occur after updating to the new font packages. As such, since FC5 is very close, in line with keeping risks to a minimum this late in the cycle, I want to get as many people as possible to upgrade to the new font packages and provide feedback before I consider putting them into rawhide. Please download the following font rpms, and upgrade to all of them with "rpm -Uvh *.rpm" and report back any error messages that occur, or any problems that occur after upgrading to the new packages. Please reboot your system so that xfs, the X server, and whatnot are all completely restarted to maximize the testing benefit. xorg-x11-fonts-7.0-2 is now available for download via ftp at the following URL: ftp://people.redhat.com/mharris/testing/unstable Additionally, I have put a diff of the spec file changes I've made in a file attachment in the bug. Peer review of the changes are also appreciated. The idea here is to try to avoid last minute catastrophes from entering the fray. Your help in testing this is greatly appreciated. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173875 Thanks in advance. -- Mike A. Harris, Systems Engineer, X11 Development team, Red Hat Canada, Ltd. From ivg2 at cornell.edu Fri Feb 24 15:48:57 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 24 Feb 2006 10:48:57 -0500 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <604aa7910602240736pd56fc20i50991a38038b9300@mail.gmail.com> References: <43FD0AC0.2090702@redhat.com> <43FD78EC.4080104@3di.it> <43FEDE89.5050301@mharris.ca> <20060224150827.GB25256@wolff.to> <43FF25E9.1080802@cornell.edu> <604aa7910602240736pd56fc20i50991a38038b9300@mail.gmail.com> Message-ID: <43FF2AE9.5000101@cornell.edu> > Correction.. non-crackrock rpms would not create a problem. You can > do an amazing amount of damage via postinstall scripts inside > packages. It wouldn't be all that difficult to create an nvidia rpm > that dropped the nvidia installer on the system and then ran the > installer via postinstall script. In fact I'm pretty sure I've seen > that sort of beast in the wild at some point. If your security is so > tight that postinstall actions during rpm packages would generally > fail when tampering with other package's files.. then you break lots > of postinstall actions. > I think rpm scripts already run within rpm_script_t domain which is confined on strict policy. Not sure how extensive the confinement is (I don't think it's very extensive). What kind of scripts legitimately need to tamper with other packages' files? Examples? From jspaleta at gmail.com Fri Feb 24 15:52:44 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 24 Feb 2006 10:52:44 -0500 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <43FF2AE9.5000101@cornell.edu> References: <43FD0AC0.2090702@redhat.com> <43FD78EC.4080104@3di.it> <43FEDE89.5050301@mharris.ca> <20060224150827.GB25256@wolff.to> <43FF25E9.1080802@cornell.edu> <604aa7910602240736pd56fc20i50991a38038b9300@mail.gmail.com> <43FF2AE9.5000101@cornell.edu> Message-ID: <604aa7910602240752r78beccceu9b4cb34406bfda7a@mail.gmail.com> On 2/24/06, Ivan Gyurdiev wrote: > What kind of scripts legitimately need to tamper with other packages' > files? Examples? I take you you mean non config file examples? -jef From rnicholsNOSPAM at comcast.net Fri Feb 24 15:55:39 2006 From: rnicholsNOSPAM at comcast.net (Robert Nichols) Date: Fri, 24 Feb 2006 09:55:39 -0600 Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) In-Reply-To: References: <200602240944.k1O9ixln016849@tiffany.internal.tigress.co.uk> <20060224124517.0fd0686e@dhcp05.addix.net> <43FEF700.7070905@cornell.edu> Message-ID: Benjy Grogan wrote: > I'm in favor of SELinux. I've heard that when writing these policies > the developers have actually improved the applications themselves. They > realized that an application didn't really need this or that permission > and so they adjusted the code and wrote an even better policy. SELinux > seems to have some use in debugging software. > > If people are afraid of SELinux I think what's need is more education on > it. more "layman" articles getting across a few of the "ideas" behind > SELinux. The problem with SELinux is that anyone whose use of a computer involves more than clicking on icons is pretty much forced to become an SELinux guru. Simple things like "ping xxx >$HOME/ping.result" failing because ping isn't allowed to write to user_home_t don't make people big fans of SELinux. I fought with SELinux for quite a while, left it in permissive mode, ran audit2allow on whatever complaints turned up, and resolved to use enforcing mode if I could ever get through a week without seeing more "AVC ... denied" complaints. Never made it. Finally gave up, deleted the ACLs from the file systems, and added "selinux=0" as a kernel parameter. -- Bob Nichols Yes, "NOSPAM" is really part of my email address. From bruno at wolff.to Fri Feb 24 16:16:50 2006 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 24 Feb 2006 10:16:50 -0600 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <43FF254C.2020705@mharris.ca> References: <43FD0AC0.2090702@redhat.com> <43FD78EC.4080104@3di.it> <43FEDE89.5050301@mharris.ca> <20060224150827.GB25256@wolff.to> <43FF254C.2020705@mharris.ca> Message-ID: <20060224161650.GA9718@wolff.to> On Fri, Feb 24, 2006 at 10:25:00 -0500, "Mike A. Harris" wrote: > > 2) Would make people get upset at SElinux and probably disable it if > they don't already. I admit I did that for FC3, but I really like targetted for FC4. I had a couple issues with httpd where I had some stuff outside the /var/www/html tree that needed to marked with the correct context and a few perl scripts that needed more access (mostly acces to postgres and one talks to a remote host) that I made unconstrained (though I am trying to learn enough to tighten them back up). I really want to try out strict. I think I know enough now to be able to work through problems and I don't like programs having network access by default. This includes some CD players supplied by fedora that are configured to do remote lookups by default. I also don't trust game software provided by commercial vendors. When I upgrade to FC5 I am going to at least try it out. > Everyone is given an OS to install and use, and with that freedom > comes responsibility. You're given the rope to hang yourself with > in thousands of places in Linux and Linux-like OSs. It is entirely > the responsibility of the system administrator, or user responsible > for the computer system to ensure that they are installing software > wisely. Currently that is a real pain to do, depending on how much trust you give to various vendors. Ideally you would like a separate environment for each different source of software that you want to install. So that when you do installs, the install scripts can't do some things (phone home, install DRM, etc.). You can kind of do that now by creating a separate account for each source and setting up necessary directories with appropiate ownership before doing the install. While I did something like this for neverwinter nights, so I could restrict its network access by user in my packet filter, this gets tiring after a while. SELinux isn't going to solve this problem either, but I might be able to have it block some bad behavior for me without spending as much effort. From bruno at wolff.to Fri Feb 24 16:21:33 2006 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 24 Feb 2006 10:21:33 -0600 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <43FF25E9.1080802@cornell.edu> References: <43FD0AC0.2090702@redhat.com> <43FD78EC.4080104@3di.it> <43FEDE89.5050301@mharris.ca> <20060224150827.GB25256@wolff.to> <43FF25E9.1080802@cornell.edu> Message-ID: <20060224162133.GB9718@wolff.to> On Fri, Feb 24, 2006 at 10:27:37 -0500, Ivan Gyurdiev wrote: > > You'd enumerate all the contexts for files under /lib, /usr/lib, etc.. > places which would be declared "controlled" by rpm. > Then you create a new attribute called "managed" or something like that, > and mark all those types with that attribute. > Then you write policy to allow rpm to manage those types. You write an > assertion to make sure nothing but rpm manages those files. Then audit > and remove all rules from policy that violate that assertion. I haven't > written policy in a while, but shouldn't this work? You're right you could do that. There wouldn't be just one 'managed' context though. You'd have to make a 'managed' version of each existing context that was used in those directories. Its a bit more work, but would be doable. From ivg2 at cornell.edu Fri Feb 24 16:15:03 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 24 Feb 2006 11:15:03 -0500 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <604aa7910602240752r78beccceu9b4cb34406bfda7a@mail.gmail.com> References: <43FD0AC0.2090702@redhat.com> <43FD78EC.4080104@3di.it> <43FEDE89.5050301@mharris.ca> <20060224150827.GB25256@wolff.to> <43FF25E9.1080802@cornell.edu> <604aa7910602240736pd56fc20i50991a38038b9300@mail.gmail.com> <43FF2AE9.5000101@cornell.edu> <604aa7910602240752r78beccceu9b4cb34406bfda7a@mail.gmail.com> Message-ID: <43FF3107.1050807@cornell.edu> >> What kind of scripts legitimately need to tamper with other packages' >> files? Examples? >> > > I take you you mean non config file examples Right now I see things like this in the current policy for rpm_script_t (on strict, no less...): Not sure why all of those things are necessary... # ideally we would not need this auth_manage_all_files_except_shadow(rpm_script_t) # ideally we would not need this dev_manage_generic_blk_files(rpm_script_t) dev_manage_generic_chr_files(rpm_script_t) dev_manage_all_blk_files(rpm_script_t) dev_manage_all_chr_files(rpm_script_t) storage_raw_read_fixed_disk(rpm_script_t) storage_raw_write_fixed_disk(rpm_script_t) From marcel at mesa.nl Fri Feb 24 16:34:17 2006 From: marcel at mesa.nl (Marcel J.E. Mol) Date: Fri, 24 Feb 2006 17:34:17 +0100 Subject: udev problems and starting KDE In-Reply-To: <43FF17C6.50107@redhat.com> References: <20060224134746.GA9846@joshua.mesa.nl> <43FF17C6.50107@redhat.com> Message-ID: <20060224163417.GA12522@joshua.mesa.nl> On Fri, Feb 24, 2006 at 03:27:18PM +0100, Harald Hoyer wrote: > Marcel J.E. Mol wrote: > >Hello, > > > >Upgraded rawhide from a couple of weeksa go to rawhide of yesterday. > >When booting I get a load of udev messages: > > > > Starting udev: udevd-event[592]: wait_for_sysfs: waiting for > > '/sys/class/tty/ttyS0/bus' failed > > udevd-event[595]: wait_for_sysfs: waiting for > > '/sys/block/hde/hde1/bus' failed > > udevd-event[1084]: wait_for_sysfs: waiting for '/sys/block/fd0/bus' > > failed > > > > Try to remove the line with WAIT_FOR_SYSFS="bus" in > /etc/udev/rules.d/05-udev-early.rules and restart. Ok that silenced the udev messages. Thanks. But I wonder if something is still wrong or not? And unfortunately kde/gnome still does not work for non-root users. I'll post a new topic on that... -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 harald at redhat.com Fri Feb 24 16:39:48 2006 From: harald at redhat.com (Harald Hoyer) Date: Fri, 24 Feb 2006 17:39:48 +0100 Subject: udev problems and starting KDE In-Reply-To: <43FF17C6.50107@redhat.com> References: <20060224134746.GA9846@joshua.mesa.nl> <43FF17C6.50107@redhat.com> Message-ID: <43FF36D4.3000505@redhat.com> Harald Hoyer wrote: > Try to remove the line with WAIT_FOR_SYSFS="bus" in > /etc/udev/rules.d/05-udev-early.rules and restart. > Ok... better replace that with: ACTION=="add", DEVPATH=="/devices/*", ENV{PHYSDEVBUS}=="?*", WAIT_FOR_SYSFS="bus" From cmadams at hiwaay.net Fri Feb 24 16:41:11 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 24 Feb 2006 10:41:11 -0600 Subject: Virtual machine software for Fedora testing? In-Reply-To: <1140792211.21535.32.camel@localhost.localdomain> References: <1cef3e950602231322u3c43f267k1a08290cf8755c47@mail.gmail.com> <43FE28A2.20906@cygnusx-1.org> <43FF161C.8030805@redhat.com> <1140792211.21535.32.camel@localhost.localdomain> Message-ID: <20060224164111.GF858544@hiwaay.net> Once upon a time, Nigel Metheringham said: > Xen is a para-virtualisation system - the virtualised system/os needs to > built in a way that is appropriate for virtualising. This means that > you are (currently) unable to use xen for running windows images or even > installing older (non xen aware) versions of Linux. Not entirely true: with new versions of Xen combined with certain CPUs (Intels today, AMDs some time this year), you can have full virtualization. People are running Windows along side Linux. There's a higher overhead in running that way, so it is preferred to run with a Xen-aware OS. Also note: I haven't tried this myself yet. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From mknepher at bluethingy.com Fri Feb 24 17:14:55 2006 From: mknepher at bluethingy.com (Michael Knepher) Date: Fri, 24 Feb 2006 09:14:55 -0800 Subject: Notification bubble In-Reply-To: References: <1140740629.32082.18.camel@lionel-hutz.darnell.group> Message-ID: <1140801296.5819.1.camel@lionel-hutz.darnell.group> On Fri, 2006-02-24 at 12:22 +0100, Thomas M Steenholdt wrote: > Michael Knepher wrote: > > At some point during the Gnome 2.13.x development cycle, the > > notification bubbles were changed to an irregularly shaped balloon like > > this: > > > > http://www.bluethingy.com/linux/bubble2.png > > > > (as seen on my up-to-date rawhide install) > > > > While in the latest preview for gnome-2.14, the bubbles appear to have > > reverted to the older style: > > > > http://www.gnome.org/~davyd/gnome-2-14/images/libnotify.png > > > > I've noticed that dapper also has the "new old" bubbles. > > > > Is my system messed up, is the gnome-2.14 preview incorrect, or is > > Fedora going with the hideous blue balloons? > > > > Without knowing for sure i would think that this was probably themable > and you're seeing differences in themes, perhaps? I thought the same thing, and tried different themes, but that doesn't change the bubble. > > Just a wild guess! > > /Thomas > From clydekunkel7734 at cox.net Fri Feb 24 17:18:37 2006 From: clydekunkel7734 at cox.net (Clyde E. Kunkel) Date: Fri, 24 Feb 2006 12:18:37 -0500 Subject: REQUEST FOR TESTERS: xorg-x11-fonts-7.0-2 In-Reply-To: <43FF294A.9080800@redhat.com> References: <43FF294A.9080800@redhat.com> Message-ID: <43FF3FED.4030604@cox.net> Mike A. Harris wrote: > I've built new xorg-x11-fonts packages to attempt to resolve > bug #173875. The new packages seem to resolve the issue fine > for me with local testing. > Please download the following font rpms, and upgrade to all > of them with "rpm -Uvh *.rpm" and report back any error messages > that occur, or any problems that occur after upgrading to the > new packages. Please reboot your system so that xfs, the > X server, and whatnot are all completely restarted to maximize > the testing benefit. > > Additionally, I have put a diff of the spec file changes I've > made in a file attachment in the bug. Peer review of the > changes are also appreciated. > > The idea here is to try to avoid last minute catastrophes from > entering the fray. Your help in testing this is greatly > appreciated. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173875 > > Thanks in advance. > > Worked nicely here, haven't seen any probs---logs are clean WRT fonts and xfs. /etc/X11/fs/config is good. -- Regards, Old Fart (my reply-to address is "munged" to defeat spambots) From marcel at mesa.nl Fri Feb 24 18:01:27 2006 From: marcel at mesa.nl (Marcel J.E. Mol) Date: Fri, 24 Feb 2006 19:01:27 +0100 Subject: rawhide of 20060223: KDE fails to start Message-ID: <20060224180127.GA13869@joshua.mesa.nl> Hello, (this is a repeat from my previous report on udev and kde, but as this does not seem to be related to udev, I reposted without the udev stuff). After I uppgraded rawhide from a couple of weeks ago to rawhide of yesterday. it seems not possible to start kde or gnome as a normal user. Starting kde as root works fine. (note X is running fine. Using failsafe xterm mode keeps X up and running) startkde: Starting up... DCOP aborting call from 'anonymous-776' to 'kded' startkde: Shutting down... klauncher: Exiting on signal 1 startkde: Running shutdown scripts... startkde: Done. Starting startkde from the failsafe xterm gives the same error message. I cant find any more info on waht is going wrong. KDE seems to be very silent wheng things go wrong... I reinstalled the whole kde set, and even went back to kde of FC5test3, but that does not help. Also removing the .kde tree does not help. Any suggestions? Thanks -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 dax at gurulabs.com Fri Feb 24 18:53:38 2006 From: dax at gurulabs.com (Dax Kelson) Date: Fri, 24 Feb 2006 11:53:38 -0700 Subject: kernel-smp-2.6.15-1.1977_FC5 hangs on boot Message-ID: <1140807218.3475.16.camel@mentorng.gurulabs.com> FYI I have a FC5test3 box, I did a yum update about a hundred packages were updated including kernel-smp-2.6.15-1.1977_FC5. With 1977, the system hangs on boot. The last line printed on the screen is: "Write protecting the kernel read-only data: 368k" I believe this is the bug for it. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182731 Dax Kelson From gnomeuser at gmail.com Fri Feb 24 19:00:42 2006 From: gnomeuser at gmail.com (David Nielsen) Date: Fri, 24 Feb 2006 20:00:42 +0100 Subject: kernel-smp-2.6.15-1.1977_FC5 hangs on boot In-Reply-To: <1140807218.3475.16.camel@mentorng.gurulabs.com> References: <1140807218.3475.16.camel@mentorng.gurulabs.com> Message-ID: <1140807644.2143.0.camel@price.stavtrup-st.dk> fre, 24 02 2006 kl. 11:53 -0700, skrev Dax Kelson: > FYI > > I have a FC5test3 box, I did a yum update about a hundred packages were > updated including kernel-smp-2.6.15-1.1977_FC5. > > With 1977, the system hangs on boot. > > The last line printed on the screen is: > > "Write protecting the kernel read-only data: 368k" > > I believe this is the bug for it. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182731 > I can confirm this, I have a UP machine but I run the SMP kernel as it tends to hit more bugs that way. - David -- Obligatory shameless blog plug - the GNOME commentary located at: www.lovesunix.net/blog From arjan at fenrus.demon.nl Fri Feb 24 19:11:25 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Fri, 24 Feb 2006 20:11:25 +0100 Subject: kernel-smp-2.6.15-1.1977_FC5 hangs on boot In-Reply-To: <1140807218.3475.16.camel@mentorng.gurulabs.com> References: <1140807218.3475.16.camel@mentorng.gurulabs.com> Message-ID: <1140808286.2874.28.camel@laptopd505.fenrus.org> On Fri, 2006-02-24 at 11:53 -0700, Dax Kelson wrote: > FYI > > I have a FC5test3 box, I did a yum update about a hundred packages were > updated including kernel-smp-2.6.15-1.1977_FC5. > > With 1977, the system hangs on boot. > > The last line printed on the screen is: > > "Write protecting the kernel read-only data: 368k" is it still the last thing printed if you add "debug" to the kernel options (and remove "quiet" if that is still there) From michael.favia at insitesinc.com Fri Feb 24 19:15:01 2006 From: michael.favia at insitesinc.com (Michael Favia) Date: Fri, 24 Feb 2006 13:15:01 -0600 Subject: Cross posting. Message-ID: <43FF5B35.9030900@insitesinc.com> There is an awful lot of cross posting between test and devel these days. It gets pretty tiresome deleting threads that are exact duplicates on both lists and im afraid the only result is the possible deletion of something that is pertinent to the respective list. Is this desired or expected activity? I'd cross post this but i think vaguely i remember something about pots and kettles. -mf From k.georgiou at imperial.ac.uk Fri Feb 24 19:28:20 2006 From: k.georgiou at imperial.ac.uk (Kostas Georgiou) Date: Fri, 24 Feb 2006 19:28:20 +0000 Subject: kernel-smp-2.6.15-1.1977_FC5 hangs on boot In-Reply-To: <1140808286.2874.28.camel@laptopd505.fenrus.org> References: <1140807218.3475.16.camel@mentorng.gurulabs.com> <1140808286.2874.28.camel@laptopd505.fenrus.org> Message-ID: <20060224192820.GA27467@imperial.ac.uk> On Fri, Feb 24, 2006 at 08:11:25PM +0100, Arjan van de Ven wrote: > On Fri, 2006-02-24 at 11:53 -0700, Dax Kelson wrote: > > FYI > > > > I have a FC5test3 box, I did a yum update about a hundred packages were > > updated including kernel-smp-2.6.15-1.1977_FC5. > > > > With 1977, the system hangs on boot. > > > > The last line printed on the screen is: > > > > "Write protecting the kernel read-only data: 368k" > > > is it still the last thing printed if you add "debug" to the kernel > options (and remove "quiet" if that is still there) For me it was "SELinux: Registering netfilter hooks" if I remember correctly, I'll check again once I am back at home. From caillon at redhat.com Fri Feb 24 20:56:11 2006 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 24 Feb 2006 15:56:11 -0500 Subject: Cross posting. In-Reply-To: <43FF5B35.9030900@insitesinc.com> References: <43FF5B35.9030900@insitesinc.com> Message-ID: <43FF72EB.8030108@redhat.com> On 02/24/2006 02:15 PM, Michael Favia wrote: > I'd cross post this but i think vaguely i remember > something about pots and kettles. -mf I dunno, your post sounded awfully cross to me. ;-) From cmadams at hiwaay.net Fri Feb 24 21:13:23 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 24 Feb 2006 15:13:23 -0600 Subject: Bluetooth security Message-ID: <20060224211323.GJ858544@hiwaay.net> I'm trying to get a Bluetooth mouse working with my notebook and rawhide. I'm getting close, but I realized one thing missing: how do I set up security? When I associate my mouse with WinXP, it asks me to verify I want to do that (shows the device ID so I can make sure only my mouse works). When I turn my mouse on while the notebook is running Linux, it grabs it automatically. How do I keep just any mouse from associating with my notebook under Linux? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From dragoran at feuerpokemon.de Fri Feb 24 21:21:02 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Fri, 24 Feb 2006 22:21:02 +0100 Subject: Virtual machine software for Fedora testing? In-Reply-To: <1140793574.27580.1.camel@ignacio.lan> References: <1cef3e950602231322u3c43f267k1a08290cf8755c47@mail.gmail.com> <43FE28A2.20906@cygnusx-1.org> <43FF161C.8030805@redhat.com> <1140792211.21535.32.camel@localhost.localdomain> <1140793574.27580.1.camel@ignacio.lan> Message-ID: <43FF78BE.5050701@feuerpokemon.de> Ignacio Vazquez-Abrams wrote: >On Fri, 2006-02-24 at 14:43 +0000, Nigel Metheringham wrote: > > >>I don't think VMware >>does anything other than i386 running on i386 (unlike qemu). >> >> > >It can also do x86_64 running on x86_64, even if you're running a 32-bit >OS. It can also do limited SMP. > > > >>Qemu would be a good extras candidate. I'm a bit surprised to see its >>not in extras at present. >> >> > >It doesn't build against gcc4. > > > because its to slow without kqemu(non free) and qvm86(gpl) does not run on x86_64 (last time I tryed) From dax at gurulabs.com Fri Feb 24 21:22:10 2006 From: dax at gurulabs.com (Dax Kelson) Date: Fri, 24 Feb 2006 14:22:10 -0700 Subject: kernel-smp-2.6.15-1.1977_FC5 hangs on boot In-Reply-To: <1140808286.2874.28.camel@laptopd505.fenrus.org> References: <1140807218.3475.16.camel@mentorng.gurulabs.com> <1140808286.2874.28.camel@laptopd505.fenrus.org> Message-ID: <1140816130.3475.26.camel@mentorng.gurulabs.com> On Fri, 2006-02-24 at 20:11 +0100, Arjan van de Ven wrote: > On Fri, 2006-02-24 at 11:53 -0700, Dax Kelson wrote: > > FYI > > > > I have a FC5test3 box, I did a yum update about a hundred packages were > > updated including kernel-smp-2.6.15-1.1977_FC5. > > > > With 1977, the system hangs on boot. > > > > The last line printed on the screen is: > > > > "Write protecting the kernel read-only data: 368k" > > > is it still the last thing printed if you add "debug" to the kernel > options (and remove "quiet" if that is still there) Yes. It is still the last thing printed. Dax Kelson From nutello at sweetness.com Fri Feb 24 21:23:41 2006 From: nutello at sweetness.com (Rudi Chiarito) Date: Fri, 24 Feb 2006 22:23:41 +0100 Subject: Cross posting. In-Reply-To: <43FF5B35.9030900@insitesinc.com> References: <43FF5B35.9030900@insitesinc.com> Message-ID: <20060224212341.GH29177@plain.rackshack.net> On Fri, Feb 24, 2006 at 01:15:01PM -0600, Michael Favia wrote: > There is an awful lot of cross posting between test and devel these > days. It gets pretty tiresome deleting threads that are exact duplicates > on both lists and im afraid the only result is the possible deletion of > something that is pertinent to the respective list. Is this desired or > expected activity? I'd cross post this but i think vaguely i remember > something about pots and kettles. -mf This has been my solution for years: http://sial.org/howto/procmail/#s3 -- Rudi From brentonr at dorm.org Fri Feb 24 21:49:59 2006 From: brentonr at dorm.org (Brenton Rothchild) Date: Fri, 24 Feb 2006 15:49:59 -0600 Subject: iptables problems after kernel 1871 In-Reply-To: <1138300984.2636.8.camel@price.stavtrup-st.dk> References: <561c252c0601261033i3a0da062v@mail.gmail.com> <1138300984.2636.8.camel@price.stavtrup-st.dk> Message-ID: <43FF7F87.7000609@dorm.org> David Nielsen wrote: > tor, 26 01 2006 kl. 10:33 -0800, skrev Gianluca Cecchi: > >> Any hint? No changes made at /etc/sysconfig/iptables file. > > As I understand this is a known issue with the kernel > > - David > Just to track down more info, did this affect any of the FC4 kernels? I had a box run into all sorts of netfilter problems during network I/O this morning and it locked hard, each time after a reboot. 'chkconfig iptables off' finally got things stable again. I was running kernel-2.6.15-1.1831_FC4 on i386 with current updates on everything relevant (as far as I can determine what was relevant in this case...) Thanks! -Brenton Rothchild From briang at pmccorp.com Fri Feb 24 22:13:58 2006 From: briang at pmccorp.com (Brian Gaynor) Date: Fri, 24 Feb 2006 14:13:58 -0800 Subject: kernel-smp-2.6.15-1.1977_FC5 hangs on boot In-Reply-To: <1140807644.2143.0.camel@price.stavtrup-st.dk> References: <1140807218.3475.16.camel@mentorng.gurulabs.com> <1140807644.2143.0.camel@price.stavtrup-st.dk> Message-ID: <1140819238.7692.7.camel@canis> On Fri, 2006-02-24 at 20:00 +0100, David Nielsen wrote: > fre, 24 02 2006 kl. 11:53 -0700, skrev Dax Kelson: > > FYI > > > > I have a FC5test3 box, I did a yum update about a hundred packages were > > updated including kernel-smp-2.6.15-1.1977_FC5. > > > > With 1977, the system hangs on boot. > > > > The last line printed on the screen is: > > > > "Write protecting the kernel read-only data: 368k" > > > > I believe this is the bug for it. > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182731 > > > > I can confirm this, I have a UP machine but I run the SMP kernel as it > tends to hit more bugs that way. > > - David > -- > Obligatory shameless blog plug - the GNOME commentary located at: > www.lovesunix.net/blog Similar problem on a Dell Inspiron 5160, freezes right after the Synaptics touchpad. -- Brian Gaynor www.pmccorp.com FC4/Linux on DELL Inspiron 5160 3.0Ghz canis 14:12:45 up 5:08, 1 user, load average: 0.11, 0.23, 0.19 From lamont at gurulabs.com Fri Feb 24 22:40:03 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Fri, 24 Feb 2006 15:40:03 -0700 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <43FEDF67.9090607@mharris.ca> References: <43FD0AC0.2090702@redhat.com> <200602230958.19039.lamont@gurulabs.com> <43FEDF67.9090607@mharris.ca> Message-ID: <200602241540.08794.lamont@gurulabs.com> On Friday 24 February 2006 03:26am, Mike A. Harris wrote: > Lamont R. Peterson wrote: > > On Thursday 23 February 2006 01:10am, n0dalus wrote: > >>On 2/23/06, Igor Jagec wrote: > > > > [snip] > > > >>Essentially, after installing livna's packages instead, you would need > >>to do an rpm -Va on various packages to ensure that the files hadn't > >>been replaced (If they have, reinstall those packages). > > > > Not to nit-pick, but running rpm -Va will check *all* packages; that's > > what the -a switch does. Same for rpm -qa listing all packages. Of > > course, you can also do: > > > > rpm -qa kernel* > > > > to see all packages that begin with "kernel". If you want to verify only > > certain packages with rpm, run: > > > > rpm -V package1 package2 package3 > > > > BTW: rpm -Va will take a long time to run. > > Users who are technically inclined enough to optimize the rpm verify > to a subset of all packages that just encompass all X packages, are > of course free to do so. :o) > > rpm -Va gets them all, without having to have a big explanation, or > provide a list of all of the relevent packages however. Yes, you are right about that. Of course, we're talking about 2 minutes versus (potentially) 90+ minutes to run through it. Yes, I know, those numbers depend on a lot of variables. I have to work with a lot of systems that have everything installs on them. rpm -Va takes a long time to run on those boxes. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From sundaram at fedoraproject.org Fri Feb 24 22:49:39 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 25 Feb 2006 04:19:39 +0530 Subject: gnome 2.14 after FC5 released? In-Reply-To: <01f801c63897$e69a3200$f502000a@M145Primary> References: <01f801c63897$e69a3200$f502000a@M145Primary> Message-ID: <43FF8D83.9070603@fedoraproject.org> Eric Wood wrote: > Since the release dates for gnome 2.14 and FC5 are the same, and the > devel freeze is even earlier, will the gnome 2.14 probably be released > as an update? > Likely. > I know there was some talk about sliding FC5 just for the sake of > gnome 2.14 and it performance benefits. I was just wondering what > the latest concensus was. Staying as close to GNOME 2.14 as reasonable before the freeze seems to be the consensus now. If the release is going to be delayed any further there are going to be other reasons. GNOME performance enhancements are already in rawhide. -- Rahul From marcel at mesa.nl Fri Feb 24 23:31:16 2006 From: marcel at mesa.nl (Marcel J.E. Mol) Date: Sat, 25 Feb 2006 00:31:16 +0100 Subject: rawhide of 20060223: KDE fails to start In-Reply-To: <20060224180127.GA13869@joshua.mesa.nl> References: <20060224180127.GA13869@joshua.mesa.nl> Message-ID: <20060224233116.GA17915@joshua.mesa.nl> On Fri, Feb 24, 2006 at 07:01:27PM +0100, Marcel J.E. Mol wrote: > Hello, > > (this is a repeat from my previous report on udev and kde, but as this does not > seem to be related to udev, I reposted without the udev stuff). > > After I uppgraded rawhide from a couple of weeks ago to rawhide of yesterday. > it seems not possible to start kde or gnome as a normal user. Starting kde > as root works fine. (note X is running fine. Using failsafe xterm mode keeps > X up and running) > > startkde: Starting up... > DCOP aborting call from 'anonymous-776' to 'kded' > startkde: Shutting down... > klauncher: Exiting on signal 1 > startkde: Running shutdown scripts... > startkde: Done. > > Starting startkde from the failsafe xterm gives the same error message. > I cant find any more info on waht is going wrong. KDE seems to be very > silent wheng things go wrong... > > I reinstalled the whole kde set, and even went back to kde of FC5test3, > but that does not help. Also removing the .kde tree does not help. > > Any suggestions? Right, solved it. I needed to remove the fontcache in ~/.rh-fontconfig -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 paul at all-the-johnsons.co.uk Sat Feb 25 00:23:30 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 25 Feb 2006 00:23:30 +0000 Subject: Another OOo x86_64 kablooey! Message-ID: <1140827011.12922.13.camel@T7.Linux> Hi, Try to import a M$ Windross presentation into OOimpress and watch it fall over. Joy! TTFN Paul -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From dishkuvek at dclam.com Sat Feb 25 02:33:05 2006 From: dishkuvek at dclam.com (Dick Dishkuvek) Date: Fri, 24 Feb 2006 21:33:05 -0500 Subject: Ralink rt2500, can't load module In-Reply-To: <43FB7DC9.8060307@vip.hr> References: <43FB7DC9.8060307@vip.hr> Message-ID: <1140834785.5730.2.camel@localhost.localdomain> On Tue, 2006-02-21 at 21:53 +0100, Igor Jagec wrote: > I compiled beta3 and cvs drivers on FC5t3 and everything went ok, but > the rt2500 module can't be loaded. On FC5t2's default kernel everything > went ok (both, compiling and loading the rt2500 module). > > [root at localhost Module]# /sbin/modprobe rt2500 > FATAL: Error inserting rt2500 > (/lib/modules/2.6.15-1.1955_FC5/extra/rt2500.ko): Invalid argument > > Is it any way to load that module? No rt2500 support means no internet > for me :-/ > > Thanks. Cheers! > > -- > Igor Jagec > You can fix it with my patch: for beta3 http://dclam.com/share/param_patch_b3.txt for cvs http://dclam.com/share/param_patch_cvs.txt go to Modules dir and: $ patch -p2 < ../../param_patch_b3.txt that assumes you are using beta 3, and that the patch is two levels down. From jbarnes at virtuousgeek.org Sat Feb 25 03:19:34 2006 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Fri, 24 Feb 2006 19:19:34 -0800 Subject: gphoto2 problem: usb access for non root users In-Reply-To: <561c252c0601311402s2dfa06d3s@mail.gmail.com> References: <561c252c0601311402s2dfa06d3s@mail.gmail.com> Message-ID: <200602241919.34962.jbarnes@virtuousgeek.org> On Tuesday, January 31, 2006 2:02 pm, Gianluca Cecchi wrote: > On Tue, 31 Jan 2006 22:04:59 +0100 Gianluca Cecchi wrote: > >> Asap I'll reboot ala windows and see if anything changes... ;-( > > Actually I did: > - init 3 > - yum update of other latest packages > - init 5 > - re-login in gnome as gcecchi > - plug digicamera > - all ok now! Hm, I haven't been so lucky. When I plugin my camera, I get a popup under KDE asking me if I want to open a window. If I select 'yes' the window comes up but times out saying it couldn't claim the usb device, presumably because both /proc/bus/usb and /dev/bus/usb are owned completely by root. My /usr/libexec/gphoto-udev-thunk-set-my-perms script has the right lines to set the perms, but maybe HAL isn't setting the right env. vars for it when it's called? Jesse From benjy.grogan at gmail.com Sat Feb 25 07:19:10 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Sat, 25 Feb 2006 02:19:10 -0500 Subject: Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.)) In-Reply-To: References: <200602240944.k1O9ixln016849@tiffany.internal.tigress.co.uk> <20060224124517.0fd0686e@dhcp05.addix.net> <43FEF700.7070905@cornell.edu> Message-ID: On 2/24/06, Robert Nichols wrote: > > Benjy Grogan wrote: > > I'm in favor of SELinux. I've heard that when writing these policies > > the developers have actually improved the applications themselves. They > > realized that an application didn't really need this or that permission > > and so they adjusted the code and wrote an even better policy. SELinux > > seems to have some use in debugging software. > > > > If people are afraid of SELinux I think what's need is more education on > > it. more "layman" articles getting across a few of the "ideas" behind > > SELinux. > > The problem with SELinux is that anyone whose use of a computer involves > more than clicking on icons is pretty much forced to become an SELinux > guru. Simple things like "ping xxx >$HOME/ping.result" failing because > ping isn't allowed to write to user_home_t don't make people big fans > of SELinux. I fought with SELinux for quite a while, left it in > permissive mode, ran audit2allow on whatever complaints turned up, and > resolved to use enforcing mode if I could ever get through a week > without seeing more "AVC ... denied" complaints. Never made it. > Finally gave up, deleted the ACLs from the file systems, and added > "selinux=0" as a kernel parameter. > Lots of work to be done. Security must be taken seriously. Higher-level functionality will hopefully make SELinux easier to use in future. Can't compromise on security. Powerful security must become mainstream. Benjy -------------- next part -------------- An HTML attachment was scrubbed... URL: From sankar at redhat.com Sat Feb 25 08:04:14 2006 From: sankar at redhat.com (Sankarshan Mukhopadhyay) Date: Sat, 25 Feb 2006 13:34:14 +0530 Subject: Another OOo x86_64 kablooey! In-Reply-To: <1140827011.12922.13.camel@T7.Linux> References: <1140827011.12922.13.camel@T7.Linux> Message-ID: <44000F7E.5090309@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul wrote: > Try to import a M$ Windross presentation into OOimpress and watch it > fall over. Joy! OO.o version and do you have a sample presentation one can try out ? - -SM -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFEAA9k+g4kmZ76nyERAhndAJ0Z+kl0dDlmyDEDnVDV9GOg+mxn3wCfYHwV wR6vBKaDCfFrTXai3yU3lUI= =cR2l -----END PGP SIGNATURE----- From buildsys at redhat.com Sat Feb 25 08:16:49 2006 From: buildsys at redhat.com (Build System) Date: Sat, 25 Feb 2006 03:16:49 -0500 Subject: rawhide report: 20060225 changes Message-ID: <200602250816.k1P8GnSl023832@porkchop.devel.redhat.com> Updated Packages: NetworkManager-0.5.1-14.cvs20060221 ----------------------------------- * Fri Feb 24 2006 Dan Williams 0.5.1-14.cvs20060221 - Move libnotify requires to NetworkManager-gnome, not core NM package anaconda-10.92.11-1 ------------------- * Fri Feb 24 2006 Jeremy Katz - 10.92.11-1 - fix traceback with segv handler (pjones) - various language fixes (dcantrel) - be clearer about askmethod (#182535) chkconfig-1.3.29-1 ------------------ * Fri Feb 24 2006 Bill Nottingham 1.3.29-1 - fix accidental enabling of services on --add (#182729) dictd-1.9.15-6 -------------- * Mon Feb 20 2006 Karsten Hopp 1.9.15-6 - BuildRequires: byacc e2fsprogs-1.38-9 ---------------- * Fri Feb 24 2006 Peter Jones - 1.38-9 - _don't_ handle selinux context on blkid.tab, dwalsh says this is a no-no. * Wed Feb 22 2006 Peter Jones - 1.38-8 - handle selinux context on blkid.tab * Mon Feb 20 2006 Karsten Hopp 1.38-7 - BuildRequires: gettext-devel f-spot-0.1.10-1 --------------- * Fri Feb 24 2006 Christopher Aillon 0.1.10-1 - Update to 0.1.10 firefox-1.5.0.1-5 ----------------- * Mon Feb 20 2006 Christopher Aillon - 1.5.0.1-5 - Rebuild * Mon Feb 20 2006 Christopher Aillon - 1.5.0.1-4 - Ensure our wrapper handles URLs with commas/spaces (Ilya Konstantinov) - Fix a pango typo freeglut-2.4.0-4 ---------------- * Tue Feb 21 2006 Karsten Hopp 2.4.0-4 - BuildRequires: libGLU-devel gdm-1:2.13.0.8-5 ---------------- * Fri Feb 24 2006 Ray Strode - 1:2.13.0.8-5 - change some /etc/X11 bits in the spec file to /etc gettext-0.14.5-3 ---------------- * Wed Feb 22 2006 Karsten Hopp 0.14.5-3 - --disable-csharp, otherwise it'll build a dll when mono is installed in the buildroot. * Fri Feb 10 2006 Jesse Keating - 0.14.5-3 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 0.14.5-2.2.1 - rebuilt for new gcc4.1 snapshot and glibc changes glib2-2.10.0-1 -------------- * Fri Feb 24 2006 Matthias Clasen - 2.10.0-1 - Update to 2.10.0 gnome-games-1:2.13.8-1 ---------------------- * Thu Feb 23 2006 Matthias Clasen - 2.13.8-1 - Update to 2.13.8 gnome-mount-0.4-2 ----------------- * Mon Feb 13 2006 David Zeuthen - 0.4-2 - Fix mounting of drives that HAL cannot poll * Mon Feb 13 2006 David Zeuthen - 0.4-1 - Update to upstream version 0.4 * Mon Feb 13 2006 Jesse Keating - 0.4-0.cvs20060213.1.1 - rebump for build order issues during double-long bump gnome-volume-manager-1.5.13-3 ----------------------------- * Fri Feb 24 2006 David Zeuthen - 1.5.13-3 - Make sure autostart desktop file gets installed in /etc/xdg/autostart * Fri Feb 24 2006 David Zeuthen - 1.5.13-2 - Shuffle some patches around to actually build this thing * Fri Feb 24 2006 David Zeuthen - 1.5.13-1 - Update to upstream release 1.5.13 - Require gnome-mount - Include patch for handling encrypted file systems gtk2-2.8.12-8 ------------- * Fri Feb 24 2006 Ray Strode - 2.8.12-8 - add dependency on hicolor * Sat Feb 11 2006 Matthias Clasen - 2.8.12-7.1 - Update to 2.8.12 * Fri Feb 10 2006 Jesse Keating - 2.8.11-7.1 - bump again for double-long bug on ppc(64) gtk2-engines-2.7.4-2 -------------------- * Fri Feb 24 2006 Matthias Clasen - 2.7.4-2 - Backport patches to draw default buttons and inconsistent checkboxes hal-0.5.7-1 ----------- * Fri Feb 24 2006 David Zeuthen - 0.5.7-1 - New upstream version 0.5.7 with several bug fixes - Don't restart hald on package upgrade - Pull in dmidecode on x86-ish and x86_64 architectures - Don't let HAL's Mount() method circumvent system policy (#182352) - Patch to use new pm-utils's new pm-powersave util properly hwdata-0.177-1 -------------- * Fri Feb 24 2006 Bill Nottingham - 0.177-1 - remove stock videoaliases in favor of driver-specific ones in the X driver packages libX11-1.0.0-3 -------------- * Thu Feb 23 2006 Christopher Aillon - 1.0.0-3 - Look for the versioned libXcursor.so.1 (fixes 179044) mkinitrd-5.0.28-1 ----------------- * Fri Feb 24 2006 Peter Jones - 5.0.28-1 - Make /dev/efirtc on ia64 boxes (#182598) - Handle selinux contexts on /etc/blkid.tab* since we can't do it in libblkid. - Make building from the "nash" subdir work again - Make getpathbyspec() allocate on the caller's stack, eliminating several memory leaks in callers. - Don't strip nash nautilus-cd-burner-2.13.91-2 ---------------------------- * Fri Feb 24 2006 Matthias Clasen - 2.13.91-2 - Fix a problem with writing iso images (#182358) nss_db-2.2-35 ------------- * Fri Feb 17 2006 Nalin Dahyabhai - 2.2-35 - add missing 'ed' builddep - set LDFLAGS and CPPFLAGS so that our local copy of DB is more likely to be found by the configure script nss_ldap-249-1 -------------- * Fri Feb 24 2006 Nalin Dahyabhai - 249-1 - update to 249, which incorporates the fix for #182464 * Thu Feb 23 2006 Nalin Dahyabhai - 248-3 - fix deadlock in initgroups() (#182464, upstream #255) policycoreutils-1.29.26-2 ------------------------- * Thu Feb 23 2006 Dan Walsh 1.29.26-2 - Change audit2allow to use devel instead of refpolicy * Mon Feb 20 2006 Dan Walsh 1.29.26-1 - Update from upstream * Merged semanage bug fix patch from Ivan Gyurdiev. * Merged improve bindings patch from Ivan Gyurdiev. * Merged semanage usage patch from Ivan Gyurdiev. * Merged use PyList patch from Ivan Gyurdiev. * Mon Feb 13 2006 Dan Walsh 1.29.23-1 - Update from upstream * Merged newrole -V/--version support from Glauber de Oliveira Costa. * Merged genhomedircon prefix patch from Dan Walsh. * Merged optionals in base patch from Joshua Brindle. pykickstart-0.22-1 ------------------ * Fri Feb 24 2006 Chris Lumens 0.22-1 - Get ignoredisk working again (#182934). rhpl-0.183-1 ------------ * Fri Feb 24 2006 Chris Lumens 0.183-1 - Fix keyboard layout switching (#173267). scim-1.4.4-6 ------------ * Fri Feb 24 2006 Jens Petersen - 1.4.4-6 - add scim-system-default-config.patch - default to Shared Input Mode (#166841) - use static XIM event flow so deadkeys work under XIM in off state (#169975) - fix paging button placement for vertical candidate windows with scim-1.4.4-candidate-vert-scroll.patch (suzhe) - fix Punjabi spelling with scim-panjabi-punjabi.patch (aalam) * Mon Feb 20 2006 Warren Togami - 1.4.4-5 - Add epoch to iiimf Obsoletes so it actually removes it (#173071) NOTE: The goal of these Obsoletes is for the official supported upgrade path to work smoothly. If users want to use iiimf, they are free to do so but their package must be compatible. * Fri Feb 10 2006 Jesse Keating - 1.4.4-4.1 - bump again for double-long bug on ppc(64) selinux-policy-2.2.21-7 ----------------------- * Thu Feb 23 2006 Dan Walsh 2.2.21-7 - Fixes for new version of cups * Thu Feb 23 2006 Dan Walsh 2.2.21-6 - Turn off polyinstatiate util after FC5 * Thu Feb 23 2006 Dan Walsh 2.2.21-5 - Fix problem with privoxy talking to Tor system-config-kickstart-2.6.6-2 ------------------------------- * Fri Feb 24 2006 Chris Lumens 2.6.6-2 - Add requirement for scriptlets (#182865, #182866). udev-084-6 ---------- * Fri Feb 24 2006 Harald Hoyer - 084-6 - put back original WAIT_FOR_SYSFS rule * Fri Feb 24 2006 Harald Hoyer - 084-5 - removed WAIT_FOR_SYSFS rule xorg-x11-apps-1.0.1-2 --------------------- * Fri Feb 24 2006 Mike A. Harris 1.0.1-2 - Added luit-1.0.1-locale.alias-datadir.patch to fix bug (#181785) * Fri Feb 10 2006 Jesse Keating 1.0.1-1.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-vga-4.0.0.5-2 -------------------------- * Fri Feb 24 2006 Mike A. Harris 4.0.0.5-2 - Added vga.xinf videoaliases file for ancient hardware (#182953) xorg-x11-xkbdata-1.0.1-4 ------------------------ * Fri Feb 24 2006 Mike A. Harris 1.0.1-4 - Actually apply the xkbdata-1.0.1-cz-fix-bug177362.patch patch this time. yum-2.5.3-2 ----------- * Fri Feb 24 2006 Jeremy Katz - 2.5.3-2 - fix installyonlyn bug with tokeep > 2 (#176704) Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15-5.FC5.4.i686 requires kernel = 0:2.6.15-1.1955_FC5 GFS-kernel - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5 GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5smp cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp gnbd-kernel - 2.6.15-5.FC5.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp libbtctl - 0.6.0-5.i386 requires libopenobex.so.1 struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.i386 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.i386 requires tomcat4 Broken deps for ia64 ---------------------------------------------------------- libbtctl - 0.6.0-5.ia64 requires libopenobex.so.1()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.ia64 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.ia64 requires tomcat4 vconfig - 1.9-1.1.ia64 requires libc.so.6 vconfig - 1.9-1.1.ia64 requires libc.so.6(GLIBC_2.0) Broken deps for ppc ---------------------------------------------------------- libbtctl - 0.6.0-5.ppc requires libopenobex.so.1 struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.ppc requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.ppc requires tomcat4 Broken deps for ppc64 ---------------------------------------------------------- emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi libbtctl - 0.6.0-5.ppc64 requires libopenobex.so.1()(64bit) struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.ppc64 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.ppc64 requires tomcat4 vconfig - 1.9-1.1.ppc64 requires libc.so.6 vconfig - 1.9-1.1.ppc64 requires libc.so.6(GLIBC_2.0) Broken deps for s390 ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.s390 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.s390 requires tomcat4 Broken deps for s390x ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.s390x requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.s390x requires tomcat4 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 libbtctl - 0.6.0-5.i386 requires libopenobex.so.1 libbtctl - 0.6.0-5.x86_64 requires libopenobex.so.1()(64bit) struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.x86_64 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.x86_64 requires tomcat4 From j.w.r.degoede at hhs.nl Sat Feb 25 08:50:43 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 25 Feb 2006 09:50:43 +0100 Subject: rawhide report: 20060225 changes In-Reply-To: <200602250816.k1P8GnSl023832@porkchop.devel.redhat.com> References: <200602250816.k1P8GnSl023832@porkchop.devel.redhat.com> Message-ID: <44001A63.3010208@hhs.nl> Build System wrote: > > gettext-0.14.5-3 > ---------------- > * Wed Feb 22 2006 Karsten Hopp 0.14.5-3 > - --disable-csharp, otherwise it'll build a dll when mono is > installed in the buildroot. > And why is that a bad thing? Just put it in a separate subpackage, there might actually be people who want to use gettext in mono, or does mono already offer a similar / buildin version? Regards, Hans From chabotc at xs4all.nl Sat Feb 25 09:34:34 2006 From: chabotc at xs4all.nl (Chris Chabot) Date: Sat, 25 Feb 2006 10:34:34 +0100 Subject: FC5 test3 -- dmraid broken? In-Reply-To: <1140644322.22131.10.camel@localhost.localdomain> Message-ID: <001401c639ee$afd8f9b0$9a00000a@chabot> I'm very close to actually wanting to install FC5 on a brank-spanking-new beast of a machine, but the disk configuration of it is identical to what the initial reporter has (nvidia raid0), should I wait for a while to see a fix for these problems in the rawhide changelog, or would it be a long wait? :-) -- Chris -----Original Message----- From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of Peter Jones Sent: Wednesday, February 22, 2006 22:39 To: Dax Kelson Cc: Development discussions related to Fedora Core Subject: Re: FC5 test3 -- dmraid broken? On Wed, 2006-02-22 at 14:42 -0500, Peter Jones wrote: > Hrm. OK, that means it got farther. So try booting into the rescue > environment and adding those drives into the lvm filters, and I'll try > to figure out how to reproduce the failure. Actually, I think I see what's going wrong, and this won't help at all. -- Peter -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list From paul at all-the-johnsons.co.uk Sat Feb 25 10:02:49 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Sat, 25 Feb 2006 10:02:49 +0000 Subject: Another OOo x86_64 kablooey! In-Reply-To: <44000F7E.5090309@redhat.com> References: <1140827011.12922.13.camel@T7.Linux> <44000F7E.5090309@redhat.com> Message-ID: <1140861769.12922.24.camel@T7.Linux> Hi, > > Try to import a M$ Windross presentation into OOimpress and watch it > > fall over. Joy! > > OO.o version and do you have a sample presentation one can try out ? It's the recently released true x86_64 build and not the one currently in rawhide. Caolin was just after reports of things going bang, but didn't say if they should be put into BZ. TTFN Paul -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show From sdl.web at gmail.com Sat Feb 25 10:45:06 2006 From: sdl.web at gmail.com (leon) Date: Sat, 25 Feb 2006 10:45:06 +0000 Subject: Few issues of fedora test 3 Message-ID: Dear all, I installed fc5test3 from scratch 1 day before official announcement. And have some issues: i. Wastebasket is always empty: I have reported it as a bug. It was closed due to "Cant reproduce this problem in FC5test3. Closing". But it is still in my system. Update to the latest development won't help. Any idea how to fix it or get more debug information? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182087 ii. Mount reiserfs failed. Any fix? message from dmesg: ------------------begin------------------------------------------------- ReiserFS: hda6: found reiserfs format "3.6" with standard journal ReiserFS: hda6: using ordered data mode ReiserFS: hda6: journal params: device hda6, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hda6: checking transaction log (hda6) ReiserFS: hda6: Using r5 hash to sort names ReiserFS: hda6: warning: xattrs/ACLs enabled and couldn't find/create.reiserfs_priv. Failing mount. ------------------end--------------------------------------------------- Many thanks. -- Leon From caolanm at redhat.com Sat Feb 25 12:37:39 2006 From: caolanm at redhat.com (Caolan McNamara) Date: Sat, 25 Feb 2006 12:37:39 +0000 Subject: Another OOo x86_64 kablooey! In-Reply-To: <1140861769.12922.24.camel@T7.Linux> References: <1140827011.12922.13.camel@T7.Linux> <44000F7E.5090309@redhat.com> <1140861769.12922.24.camel@T7.Linux> Message-ID: <1140871059.4060.2.camel@localhost.localdomain> On Sat, 2006-02-25 at 10:02 +0000, Paul F. Johnson wrote: > Hi, > > > > Try to import a M$ Windross presentation into OOimpress and watch it > > > fall over. Joy! > > > > OO.o version and do you have a sample presentation one can try out ? > > It's the recently released true x86_64 build and not the one currently > in rawhide. Caolin was just after reports of things going bang, but > didn't say if they should be put into BZ. Log 'em in openoffice.org issuezilla and title "64bit: whatever" and assign to cmc at openoffice.org. Keep them restricted to major areas for now, e.g embedded formulas don't work, ppt import busted. It's just a tech preview. C. From paul at all-the-johnsons.co.uk Sat Feb 25 13:15:50 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Sat, 25 Feb 2006 13:15:50 +0000 Subject: Another OOo x86_64 kablooey! In-Reply-To: <1140871059.4060.2.camel@localhost.localdomain> References: <1140827011.12922.13.camel@T7.Linux> <44000F7E.5090309@redhat.com> <1140861769.12922.24.camel@T7.Linux> <1140871059.4060.2.camel@localhost.localdomain> Message-ID: <1140873350.12922.26.camel@T7.Linux> Hi, > Log 'em in openoffice.org issuezilla and title "64bit: whatever" and > assign to cmc at openoffice.org. Keep them restricted to major areas for > now, e.g embedded formulas don't work, ppt import busted. It's just a > tech preview. Done. Issues 62565+62566. More the week after next (I've not installed it at home as I need OOo to be stable for course work and marking) TTFN Paul -- "Tr?um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show From ericsbinaryworld at gmail.com Sat Feb 25 14:13:06 2006 From: ericsbinaryworld at gmail.com (Eric Mesa) Date: Sat, 25 Feb 2006 09:13:06 -0500 Subject: XMMS and Rhythmbox Message-ID: <440065F2.20103@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I see that with FC5 we finally moved away from calling Rhythmbox "music player" and XMMS "audio player". I remember trying to install Rhythmbox when I first had FC in order to check it out because I didn't know I already had it on my system. Plus the subtle difference between music player and audio player was a little annoying too. I'm curious, when I upgrade to FC5 (currently I'm running T3 as a VMWare player image), will this be changed in my menu to reflect what it is now being called? Thanks, - -- Eric Mesa ericsbinaryworld at gmail.com http://www.ericsbinaryworld.com Note: All emails from this address should have a GPG signature. If you have the proper setup you can use this to confirm my identity and that the email was not changed in transit. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEAGXyPvU+8ApmWXIRAvOpAKC78EjoB9bXRiNwWTjZ/DpdxjpNxACaA9Li d60/nF670g6n9hcAwJMGDRk= =Ag5j -----END PGP SIGNATURE----- From ericsbinaryworld at gmail.com Sat Feb 25 14:15:34 2006 From: ericsbinaryworld at gmail.com (Eric Mesa) Date: Sat, 25 Feb 2006 09:15:34 -0500 Subject: Pup and repos Message-ID: <44006686.5000106@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I love pup, it certainly runs a lot faster than yumex. Will it also be able to update packages from other repositories? Also, will add/remove software recognize other repos defined in /etc/yum.d/ ? Thanks, - -- Eric Mesa ericsbinaryworld at gmail.com http://www.ericsbinaryworld.com Note: All emails from this address should have a GPG signature. If you have the proper setup you can use this to confirm my identity and that the email was not changed in transit. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEAGaGPvU+8ApmWXIRArUUAKDc1EvaJU0T+TRI7eBLK8K21j2kvQCgnqTG zxwhYU5OJtnHO+0vACrkrJw= =hhmr -----END PGP SIGNATURE----- From katzj at redhat.com Sat Feb 25 15:00:09 2006 From: katzj at redhat.com (Jeremy Katz) Date: Sat, 25 Feb 2006 10:00:09 -0500 Subject: Pup and repos In-Reply-To: <44006686.5000106@gmail.com> References: <44006686.5000106@gmail.com> Message-ID: <1140879609.2415.28.camel@bree.local.net> On Sat, 2006-02-25 at 09:15 -0500, Eric Mesa wrote: > I love pup, it certainly runs a lot faster than yumex. Will it also > be able to update packages from other repositories? Also, will > add/remove software recognize other repos defined in /etc/yum.d/ ? Yep, they both follow the repository configuration in /etc/yum.repos.d Jeremy From hughsient at gmail.com Sat Feb 25 16:59:42 2006 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 25 Feb 2006 16:59:42 +0000 Subject: rawhide report: 20060225 changes In-Reply-To: <200602250816.k1P8GnSl023832@porkchop.devel.redhat.com> References: <200602250816.k1P8GnSl023832@porkchop.devel.redhat.com> Message-ID: <1140886782.5204.6.camel@localhost.localdomain> On Sat, 2006-02-25 at 03:16 -0500, Build System wrote: > hal-0.5.7-1 > ----------- > * Fri Feb 24 2006 David Zeuthen - 0.5.7-1 > - New upstream version 0.5.7 with several bug fixes > - Don't restart hald on package upgrade > - Pull in dmidecode on x86-ish and x86_64 architectures > - Don't let HAL's Mount() method circumvent system policy (#182352) > - Patch to use new pm-utils's new pm-powersave util properly This means: * That LCD brightness changing now works with PPC hardware (only for hardware that supports changing the backlight brightness from software). You can use gnome-power-manager to set policy when on AC and battery. * HAL should now detect the power button on PPC (works for my iBook clamshell), so that when pressed, the logout, shutdown, restart dialogue is displayed. You'll need a very up to date g-p-m for this to work. * HAL will can set a LowPowerMode when on battery power (just like LaptopMode), that should save even more battery power when on battery. Richard. From frankxchen at yahoo.com Sat Feb 25 18:22:20 2006 From: frankxchen at yahoo.com (Frank Chen) Date: Sat, 25 Feb 2006 10:22:20 -0800 (PST) Subject: td_ta_new returns TD_VERSION? Message-ID: <20060225182220.87297.qmail@web34710.mail.mud.yahoo.com> I am using gdbserver to debug a multi-threaded application on FC3. The call to td_ta_new returns TD_VERSION in gdbserver (thread-db.c). From gdb 6.4, the error maps to "version mismatch between libthread_db and libpthread" Both these libraries come with FC3. Does anyone know a solution to this problem? I tried setting LD_LIBRARY_PATH=/lib/tls. But it didn't help. Thanks, Frank __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mharris at redhat.com Sat Feb 25 22:10:09 2006 From: mharris at redhat.com (Mike A. Harris) Date: Sat, 25 Feb 2006 17:10:09 -0500 Subject: Request for testers to confirm nv driver mouse cursor bug Message-ID: <4400D5C1.8000603@redhat.com> If you are using Nvidia video hardware with FC5test3 or later, and the mouse cursor is invisible, or has any visible mouse pointer corruption, please add a comment to the following bug report to confirm you are having the same problem, and attach your X server log file as an uncompressed file attachment: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182517 2 chips have been identified as experiencing this problem so far, so once people have updated the report with any other chips that have the problem, I am going to disable hardware cursors on those chips by default so that things work out of the box in FC5 for as many nv users as possible. Once the upstream nv driver maintainer fixes the bugs in the driver, we'll update and drop the workaround. For those who want to track the issue in X.Org, the upstream bug is: https://bugs.freedesktop.org/show_bug.cgi?id=3009 Thanks in advance. -- Mike A. Harris, Systems Engineer, X11 Development team, Red Hat Canada, Ltd. From bojan at rexursive.com Sat Feb 25 22:25:26 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Sun, 26 Feb 2006 09:25:26 +1100 Subject: rawhide report: 20060225 changes Message-ID: <1140906326.18214.1.camel@coyote.rexursive.com> > gdm-1:2.13.0.8-5 > ---------------- > * Fri Feb 24 2006 Ray Strode - 1:2.13.0.8-5 > - change some /etc/X11 bits in the spec file to /etc The /etc/gdm/Xsession points to the wrong file in this one. It should be ../X11/xinit/Xsession, not ../xinit/Xsession. -- Bojan From rstrode at redhat.com Sat Feb 25 22:27:34 2006 From: rstrode at redhat.com (Ray Strode) Date: Sat, 25 Feb 2006 17:27:34 -0500 Subject: where to report xair problems? bugzilla component going to be added? In-Reply-To: References: Message-ID: <1140906455.3058.0.camel@halflap> Hi, > Hello! > > wouldnt it help to have a bugzilla entry somewhere for xair problems > and bugs? the component is yet missing while xair is going to get > shipped with fc5 according to the news ;) > just curious really because i couldnt find the component for fc > development. Also not sure if it makes sense at all at this point. The plan I think is to report bugs in freedesktop bugzilla. For now, assign them to krh at bitplanet.net --Ray From mailinglists at erwinrol.com Sun Feb 26 00:44:06 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sun, 26 Feb 2006 01:44:06 +0100 Subject: rawhide report: 20060225 changes In-Reply-To: <200602250816.k1P8GnSl023832@porkchop.devel.redhat.com> References: <200602250816.k1P8GnSl023832@porkchop.devel.redhat.com> Message-ID: <1140914646.7702.1.camel@xpc.home.erwinrol.com> When doing a yum update today i got the following error. Installing: kernel ##################### [ 22/130] *** glibc detected *** /sbin/grubby: munmap_chunk(): invalid pointer: 0x00007fffffdd9730 *** ======= Backtrace: ========= /lib64/libc.so.6(__libc_free+0x17a)[0x3a9566d9fa] /sbin/grubby[0x408746] /sbin/grubby[0x4088a3] /sbin/grubby[0x409892] /lib64/libc.so.6(__libc_start_main+0xf4)[0x3a9561d024] /sbin/grubby[0x402bc9] ======= Memory map: ======== 00400000-00442000 r-xp 00000000 09:00 11927771 /sbin/grubby 00541000-00545000 rw-p 00041000 09:00 11927771 /sbin/grubby 00545000-0056e000 rw-p 00545000 00:00 0 [heap] 3a95400000-3a95419000 r-xp 00000000 09:00 8814661 /lib64/ld-2.3.90.so 3a95519000-3a9551a000 r--p 00019000 09:00 8814661 /lib64/ld-2.3.90.so 3a9551a000-3a9551b000 rw-p 0001a000 09:00 8814661 /lib64/ld-2.3.90.so 3a95600000-3a95732000 r-xp 00000000 09:00 8814755 /lib64/libc-2.3.90.so 3a95732000-3a95831000 ---p 00132000 09:00 8814755 /lib64/libc-2.3.90.so 3a95831000-3a95835000 r--p 00131000 09:00 8814755 /lib64/libc-2.3.90.so 3a95835000-3a95836000 rw-p 00135000 09:00 8814755 /lib64/libc-2.3.90.so 3a95836000-3a9583b000 rw-p 3a95836000 00:00 0 3a97f00000-3a97f0d000 r-xp 00000000 09:00 8815104 /lib64/libgcc_s-4.1.0-20060219.so.1 3a97f0d000-3a9800c000 ---p 0000d000 09:00 8815104 /lib64/libgcc_s-4.1.0-20060219.so.1 3a9800c000-3a9800d000 rw-p 0000c000 09:00 8815104 /lib64/libgcc_s-4.1.0-20060219.so.1 2b0cceac9000-2b0cceaca000 rw-p 2b0cceac9000 00:00 0 2b0cceaf2000-2b0cceaf4000 rw-p 2b0cceaf2000 00:00 0 7fffffdc6000-7fffffddb000 rw-p 7fffffdc6000 00:00 0 [stack] ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vdso] /sbin/new-kernel-pkg: line 89: 2129 Aborted /sbin/grubby --add-kernel=$bootPrefix/$kernelName-$version $INITRD --copy-default $makedefault --title "$title" ${mbkernel:+--add-multiboot="$mbkernel"} ${mbargs:+--mbargs="$mbargs"} --args="root=$rootdevice $kernargs" --remove-kernel="TITLE=$title" Updating : anaconda ##################### [ 23/130] Updating : gnome-applets ##################### [ 24/130] From mailinglists at erwinrol.com Sun Feb 26 00:49:25 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sun, 26 Feb 2006 01:49:25 +0100 Subject: rawhide report: 20060225 changes In-Reply-To: <1140914646.7702.1.camel@xpc.home.erwinrol.com> References: <200602250816.k1P8GnSl023832@porkchop.devel.redhat.com> <1140914646.7702.1.camel@xpc.home.erwinrol.com> Message-ID: <1140914965.7702.3.camel@xpc.home.erwinrol.com> After the update was finished i got a large number of the following warnings/errors; rpmdb: PANIC: fatal region error detected; run recovery error: db4 error(-30977) from db->close: DB_RUNRECOVERY: Fatal error, run database recovery rpmdb: PANIC: fatal region error detected; run recovery error: db4 error(-30977) from db->close: DB_RUNRECOVERY: Fatal error, run database recovery rpmdb: PANIC: fatal region error detected; run recovery error: db4 error(-30977) from db->close: DB_RUNRECOVERY: Fatal error, run database recovery rpmdb: PANIC: fatal region error detected; run recovery error: db4 error(-30977) from db->close: DB_RUNRECOVERY: Fatal error, run database recovery rpmdb: PANIC: fatal region error detected; run recovery error: db4 error(-30977) from db->close: DB_RUNRECOVERY: Fatal error, run database recovery rpmdb: PANIC: fatal region error detected; run recovery error: db4 error(-30977) from db->close: DB_RUNRECOVERY: Fatal error, run database recovery rpmdb: PANIC: fatal region error detected; run recovery error: db4 error(-30977) from db->close: DB_RUNRECOVERY: Fatal error, run database recovery rpmdb: PANIC: fatal region error detected; run recovery error: db4 error(-30977) from dbenv->close: DB_RUNRECOVERY: Fatal error, run database recovery rpmdb: PANIC: fatal region error detected; run recovery error: db4 error(-30977) from db->close: DB_RUNRECOVERY: Fatal error, run database recovery rpmdb: PANIC: fatal region error detected; run recovery error: db4 error(-30977) from db->close: DB_RUNRECOVERY: Fatal error, run database recovery rpmdb: PANIC: fatal region error detected; run recovery From mailinglists at erwinrol.com Sun Feb 26 01:02:41 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sun, 26 Feb 2006 02:02:41 +0100 Subject: What causes a broken RPMDB ?? Message-ID: <1140915761.7702.9.camel@xpc.home.erwinrol.com> Today's update seems to have seriously broken my rpmdb. I can not execute any rpm command anymore. [root at xpc rpm]# rpm -qa rpmdb: PANIC: fatal region error detected; run recovery error: db4 error(-30977) from dbenv->open: DB_RUNRECOVERY: Fatal error, run database recovery error: cannot open Packages index using db3 - (-30977) error: cannot open Packages database in /var/lib/rpm I could fix it by removing all __db.??? files and running rpm --rebuilddb. But what i am wondering is what caused the corruption. I can't find anything in the logs (like filesystem corruption) that indicates a failure of my hardware. - Erwin From pemboa at gmail.com Sun Feb 26 07:08:02 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Sun, 26 Feb 2006 01:08:02 -0600 Subject: Fedora in need of testers? In-Reply-To: <200602081531.49233.lamont@gurulabs.com> References: <16de708d0512222319p3307eac0k476dc2b1b0a0a061@mail.gmail.com> <200602081336.23788.lamont@gurulabs.com> <16de708d0602081359w83e1d21h6c7255aa123e5e2c@mail.gmail.com> <200602081531.49233.lamont@gurulabs.com> Message-ID: <16de708d0602252308j214295e2hfb828f5e79c7ad9f@mail.gmail.com> Finally have the test machine ready. However, already having problems, the display doesn't consume the entire screen here are the specs on the system: Dell - OptiPlex GX110 Intel Pentium III Processor: 733 MHz (133MHz Bus Speed) BIOS Version: A09 Harddrive: WDC WD200BB-75AUA1 (20 GB) CD-ROW: Samsung CD-ROM SC-148F (48x) Soundcard: Intel ICH82801AA VGA: Intel 82810E DC-133 CGC Ethernet: 3Com 3c905C-TX/TX-M [Tornado] Monitor: Dell UltraScan P780 On my way to read the testers guude, have only gotten up to updating the entire system to updates-release. -------------- next part -------------- An HTML attachment was scrubbed... URL: From buildsys at redhat.com Sun Feb 26 08:32:05 2006 From: buildsys at redhat.com (Build System) Date: Sun, 26 Feb 2006 03:32:05 -0500 Subject: rawhide report: 20060226 changes Message-ID: <200602260832.k1Q8W5SA014717@porkchop.devel.redhat.com> Updated Packages: beagle-0.2.1-12 --------------- * Fri Feb 24 2006 Matthias Clasen 0.2.1-12 - Remove more "run from ." nonsense (#182709) - Don't spew tons of debug output (#182660) - Try to make the trigger more robust (#182679) fontconfig-2.3.94-1 ------------------- * Fri Feb 24 2006 Matthias Clasen - 2.3.94-1 - Update to 2.3.94 gdm-1:2.13.0.8-6 ---------------- * Sat Feb 25 2006 Ray Strode - 1:2.13.0.8-6 - fix a broken link gnome-icon-theme-2.14.1-1 ------------------------- * Sat Feb 25 2006 Matthias Clasen 2.14.1-1 - Update to 2.14.1 gnome-utils-1:2.13.93-1 ----------------------- * Sat Feb 25 2006 Matthias Clasen - 2.13.93-1 - Update to gnome-utils-2.13.93 - Update to gucharmap 1.5.3 librsvg2-2.14.0-1 ----------------- * Sat Feb 25 2006 Matthias Clasen 2.14.0-1 - Update to 2.14.0 mesa-6.4.2-5 ------------ * Sat Feb 25 2006 Mike A. Harris 6.4.2-5 - Disable the expeimental r300 DRI driver, as it has turned out to cause instability and system hangs for many users. vte-0.11.19-1.fc5.1 ------------------- * Sat Feb 25 2006 Matthias Clasen 0.11.19-1 - Update to 0.11.19 - Drop upstreamed patch xorg-x11-xfs-1:1.0.1-3 ---------------------- * Sat Feb 25 2006 Mike A. Harris 1:1.0.1-3 - Redirect output of "rm -rf fonts.dir" to /dev/null in xfs.init Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15-5.FC5.4.i686 requires kernel = 0:2.6.15-1.1955_FC5 GFS-kernel - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5 GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5smp cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp gnbd-kernel - 2.6.15-5.FC5.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp libbtctl - 0.6.0-5.i386 requires libopenobex.so.1 struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.i386 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.i386 requires tomcat4 Broken deps for ia64 ---------------------------------------------------------- libbtctl - 0.6.0-5.ia64 requires libopenobex.so.1()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.ia64 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.ia64 requires tomcat4 vconfig - 1.9-1.1.ia64 requires libc.so.6 vconfig - 1.9-1.1.ia64 requires libc.so.6(GLIBC_2.0) Broken deps for ppc ---------------------------------------------------------- libbtctl - 0.6.0-5.ppc requires libopenobex.so.1 struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.ppc requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.ppc requires tomcat4 Broken deps for ppc64 ---------------------------------------------------------- emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi libbtctl - 0.6.0-5.ppc64 requires libopenobex.so.1()(64bit) struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.ppc64 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.ppc64 requires tomcat4 vconfig - 1.9-1.1.ppc64 requires libc.so.6 vconfig - 1.9-1.1.ppc64 requires libc.so.6(GLIBC_2.0) Broken deps for s390 ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.s390 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.s390 requires tomcat4 Broken deps for s390x ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.s390x requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.s390x requires tomcat4 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 libbtctl - 0.6.0-5.x86_64 requires libopenobex.so.1()(64bit) libbtctl - 0.6.0-5.i386 requires libopenobex.so.1 struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.x86_64 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.x86_64 requires tomcat4 From jfrieben at freesurf.fr Sun Feb 26 11:19:23 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Sun, 26 Feb 2006 12:19:23 +0100 (CET) Subject: Low OpenGL performance In-Reply-To: <43FED9F8.80502@mharris.ca> References: <43FED9F8.80502@mharris.ca> Message-ID: <22693.194.94.224.254.1140952763.squirrel@jose.freesurf.fr> I wouldn't have posted my observation here if I hadn't checked in advance against other distros using "Xorg" 7.0.0 to exclude upstream issues to a reasonable extent. For both systems, I obtain 70% higher fps with the live CD of a different distro which makes it likely that the issue is a "Fedora" one. This justifies in my opinion the to post to this list and to ask for confirmation by other "Fedora Core" development testers. I further recall that e.g. "Red Hat" Bug #180150, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180150 , is due to a custom "Red Hat" patch. It is thus not at all obvious that bug reports or requests upstream are always a better idea. -JF > > It's generally a good idea to subscribe to the DRI and Mesa mailing > lists if experiencing GL performance issues or other problems. The IRC > channel #dri-devel on freenode.net is also quite useful. That's a > direct pipe to the developers, who are generally quite helpful and > often provide troubleshooting tips, etc. > > Hope this helps. > > > -- > Mike A. Harris * Open Source Advocate * http://mharris.ca > Proud Canadian. From fedora at camperquake.de Sun Feb 26 11:38:50 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 26 Feb 2006 12:38:50 +0100 Subject: rawhide report: 20060225 changes In-Reply-To: <1140886782.5204.6.camel@localhost.localdomain> References: <200602250816.k1P8GnSl023832@porkchop.devel.redhat.com> <1140886782.5204.6.camel@localhost.localdomain> Message-ID: <20060226123850.59b46d34@lain> Hi. On Sat, 25 Feb 2006 16:59:42 +0000, Richard Hughes wrote > * That LCD brightness changing now works with PPC hardware (only for > hardware that supports changing the backlight brightness from > software). You can use gnome-power-manager to set policy when on AC > and battery. Err... this has worked for, like, ages on my iBook. Gnome even displays a nice popup-window with the current setting on each keypress. same for the volume control. From hughsient at gmail.com Sun Feb 26 11:57:30 2006 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 26 Feb 2006 11:57:30 +0000 Subject: rawhide report: 20060225 changes In-Reply-To: <20060226123850.59b46d34@lain> References: <200602250816.k1P8GnSl023832@porkchop.devel.redhat.com> <1140886782.5204.6.camel@localhost.localdomain> <20060226123850.59b46d34@lain> Message-ID: <1140955050.2766.7.camel@localhost.localdomain> On Sun, 2006-02-26 at 12:38 +0100, Ralf Ertzinger wrote: > Hi. > > On Sat, 25 Feb 2006 16:59:42 +0000, Richard Hughes wrote > > > * That LCD brightness changing now works with PPC hardware (only for > > hardware that supports changing the backlight brightness from > > software). You can use gnome-power-manager to set policy when on AC > > and battery. > > Err... this has worked for, like, ages on my iBook. Gnome even displays > a nice popup-window with the current setting on each keypress. same > for the volume control. What does #lsof /dev/pmu print? You have probably pbbuttonsd installed which isn't integrated with GNOME or gnome-power-manager. With these changes to HAL, all this should "just work" without any configuration. Richard. From fedora at camperquake.de Sun Feb 26 12:10:02 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 26 Feb 2006 13:10:02 +0100 Subject: rawhide report: 20060225 changes In-Reply-To: <1140955050.2766.7.camel@localhost.localdomain> References: <200602250816.k1P8GnSl023832@porkchop.devel.redhat.com> <1140886782.5204.6.camel@localhost.localdomain> <20060226123850.59b46d34@lain> <1140955050.2766.7.camel@localhost.localdomain> Message-ID: <20060226131003.4539c78c@lain> Hi. On Sun, 26 Feb 2006 11:57:30 +0000, Richard Hughes wrote > What does #lsof /dev/pmu print? You have probably pbbuttonsd installed > which isn't integrated with GNOME or gnome-power-manager. With these > changes to HAL, all this should "just work" without any configuration. The only user of that file is gnome-settings-daemon. From sfolkwil at redhat.com Sun Feb 26 12:19:09 2006 From: sfolkwil at redhat.com (Sam Folk-Williams) Date: Sun, 26 Feb 2006 07:19:09 -0500 Subject: httpd missing mod_access? Message-ID: <44019CBD.8000906@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Looks like mod_access is missing from httpd in FC5T3. Am I missing something? [root at localhost ~]# rpm -q --filesbypkg httpd | grep mod_ httpd /usr/lib/httpd/modules/mod_actions.so httpd /usr/lib/httpd/modules/mod_alias.so httpd /usr/lib/httpd/modules/mod_asis.so httpd /usr/lib/httpd/modules/mod_auth_basic.so httpd /usr/lib/httpd/modules/mod_auth_digest.so httpd /usr/lib/httpd/modules/mod_authn_alias.so httpd /usr/lib/httpd/modules/mod_authn_anon.so httpd /usr/lib/httpd/modules/mod_authn_dbd.so httpd /usr/lib/httpd/modules/mod_authn_dbm.so httpd /usr/lib/httpd/modules/mod_authn_default.so httpd /usr/lib/httpd/modules/mod_authn_file.so httpd /usr/lib/httpd/modules/mod_authnz_ldap.so httpd /usr/lib/httpd/modules/mod_authz_dbm.so httpd /usr/lib/httpd/modules/mod_authz_default.so httpd /usr/lib/httpd/modules/mod_authz_groupfile.so httpd /usr/lib/httpd/modules/mod_authz_host.so httpd /usr/lib/httpd/modules/mod_authz_owner.so httpd /usr/lib/httpd/modules/mod_authz_user.so httpd /usr/lib/httpd/modules/mod_autoindex.so httpd /usr/lib/httpd/modules/mod_cache.so httpd /usr/lib/httpd/modules/mod_cern_meta.so httpd /usr/lib/httpd/modules/mod_cgi.so httpd /usr/lib/httpd/modules/mod_cgid.so httpd /usr/lib/httpd/modules/mod_dav.so httpd /usr/lib/httpd/modules/mod_dav_fs.so httpd /usr/lib/httpd/modules/mod_dbd.so httpd /usr/lib/httpd/modules/mod_deflate.so httpd /usr/lib/httpd/modules/mod_dir.so httpd /usr/lib/httpd/modules/mod_disk_cache.so httpd /usr/lib/httpd/modules/mod_dumpio.so httpd /usr/lib/httpd/modules/mod_env.so httpd /usr/lib/httpd/modules/mod_expires.so httpd /usr/lib/httpd/modules/mod_ext_filter.so httpd /usr/lib/httpd/modules/mod_file_cache.so httpd /usr/lib/httpd/modules/mod_filter.so httpd /usr/lib/httpd/modules/mod_headers.so httpd /usr/lib/httpd/modules/mod_ident.so httpd /usr/lib/httpd/modules/mod_imagemap.so httpd /usr/lib/httpd/modules/mod_include.so httpd /usr/lib/httpd/modules/mod_info.so httpd /usr/lib/httpd/modules/mod_ldap.so httpd /usr/lib/httpd/modules/mod_log_config.so httpd /usr/lib/httpd/modules/mod_log_forensic.so httpd /usr/lib/httpd/modules/mod_logio.so httpd /usr/lib/httpd/modules/mod_mem_cache.so httpd /usr/lib/httpd/modules/mod_mime.so httpd /usr/lib/httpd/modules/mod_mime_magic.so httpd /usr/lib/httpd/modules/mod_negotiation.so httpd /usr/lib/httpd/modules/mod_proxy.so httpd /usr/lib/httpd/modules/mod_proxy_ajp.so httpd /usr/lib/httpd/modules/mod_proxy_balancer.so httpd /usr/lib/httpd/modules/mod_proxy_connect.so httpd /usr/lib/httpd/modules/mod_proxy_ftp.so httpd /usr/lib/httpd/modules/mod_proxy_http.so httpd /usr/lib/httpd/modules/mod_rewrite.so httpd /usr/lib/httpd/modules/mod_setenvif.so httpd /usr/lib/httpd/modules/mod_speling.so httpd /usr/lib/httpd/modules/mod_status.so httpd /usr/lib/httpd/modules/mod_suexec.so httpd /usr/lib/httpd/modules/mod_unique_id.so httpd /usr/lib/httpd/modules/mod_userdir.so httpd /usr/lib/httpd/modules/mod_usertrack.so httpd /usr/lib/httpd/modules/mod_version.so httpd /usr/lib/httpd/modules/mod_vhost_alias.so httpd /var/cache/mod_proxy Thanks, Sam -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEAZy9zOw+vBsNRroRAt3DAJ42dTn1w2FFb76j4JWqIEFprC/x2gCcDeLx E45YPgyNnv9Wuby68MR4WeY= =VUmI -----END PGP SIGNATURE----- From j.w.r.degoede at hhs.nl Sun Feb 26 13:10:50 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 26 Feb 2006 14:10:50 +0100 Subject: rawhide report: 20060226 changes In-Reply-To: <200602260832.k1Q8W5SA014717@porkchop.devel.redhat.com> References: <200602260832.k1Q8W5SA014717@porkchop.devel.redhat.com> Message-ID: <4401A8DA.9060108@hhs.nl> Build System wrote: > > mesa-6.4.2-5 > ------------ > * Sat Feb 25 2006 Mike A. Harris 6.4.2-5 > - Disable the expeimental r300 DRI driver, as it has turned out to cause > instability and system hangs for many users. > 2 questions: 1) disable as in not enable by default / need manual config edit to enable, or disable as in needs recompile to enable? 2) if disable as in needs recompile, does it cause problems even when turned of by default. If not then why the disable? In my box the r300 drivers is one of the major features of the new X (if and only if it works, agreed there) Regards, Hans From avi at argo.co.il Sun Feb 26 14:27:17 2006 From: avi at argo.co.il (Avi Kivity) Date: Sun, 26 Feb 2006 16:27:17 +0200 Subject: kernel-smp-2.6.15-1.1977_FC5 hangs on boot In-Reply-To: <1140816130.3475.26.camel@mentorng.gurulabs.com> References: <1140807218.3475.16.camel@mentorng.gurulabs.com> <1140808286.2874.28.camel@laptopd505.fenrus.org> <1140816130.3475.26.camel@mentorng.gurulabs.com> Message-ID: <4401BAC5.50206@argo.co.il> Dax Kelson wrote: >On Fri, 2006-02-24 at 20:11 +0100, Arjan van de Ven wrote: > > >>On Fri, 2006-02-24 at 11:53 -0700, Dax Kelson wrote: >> >> >>>FYI >>> >>>I have a FC5test3 box, I did a yum update about a hundred packages were >>>updated including kernel-smp-2.6.15-1.1977_FC5. >>> >>>With 1977, the system hangs on boot. >>> >>>The last line printed on the screen is: >>> >>>"Write protecting the kernel read-only data: 368k" >>> >>> >>is it still the last thing printed if you add "debug" to the kernel >>options (and remove "quiet" if that is still there) >> >> > >Yes. It is still the last thing printed. > > Hey, maybe it's write-protecting the printk buffers :) -- error compiling committee.c: too many arguments to function From jsk_priv at gmx.de Sun Feb 26 15:04:49 2006 From: jsk_priv at gmx.de (Joerg Skottke) Date: Sun, 26 Feb 2006 16:04:49 +0100 Subject: What causes a broken RPMDB ?? - Issue 181363 In-Reply-To: <1140915761.7702.9.camel@xpc.home.erwinrol.com> References: <1140915761.7702.9.camel@xpc.home.erwinrol.com> Message-ID: <4401C391.1090101@gmx.de> Hi Erwin, i reported the issue some time ago (Issue 181363), there is a temporary solution which will repair your database but not solve your problem. Joerg Erwin Rol wrote: > Today's update seems to have seriously broken my rpmdb. I can not > execute any rpm command anymore. > > [root at xpc rpm]# rpm -qa > rpmdb: PANIC: fatal region error detected; run recovery > error: db4 error(-30977) from dbenv->open: DB_RUNRECOVERY: Fatal error, > run database recovery > error: cannot open Packages index using db3 - (-30977) > error: cannot open Packages database in /var/lib/rpm > > I could fix it by removing all __db.??? files and running rpm > --rebuilddb. But what i am wondering is what caused the corruption. I > can't find anything in the logs (like filesystem corruption) that > indicates a failure of my hardware. > > - Erwin > > > From jsk_priv at gmx.de Sun Feb 26 15:09:03 2006 From: jsk_priv at gmx.de (Joerg Skottke) Date: Sun, 26 Feb 2006 16:09:03 +0100 Subject: rawhide report: 20060225 changes In-Reply-To: <1140914646.7702.1.camel@xpc.home.erwinrol.com> References: <200602250816.k1P8GnSl023832@porkchop.devel.redhat.com> <1140914646.7702.1.camel@xpc.home.erwinrol.com> Message-ID: <4401C48F.20404@gmx.de> Erwin, same problem here, did you file an issue? Joerg Erwin Rol wrote: > When doing a yum update today i got the following error. > > > > Installing: kernel ##################### [ 22/130] > *** glibc detected *** /sbin/grubby: munmap_chunk(): invalid pointer: 0x00007fffffdd9730 *** > ======= Backtrace: ========= > /lib64/libc.so.6(__libc_free+0x17a)[0x3a9566d9fa] > /sbin/grubby[0x408746] > /sbin/grubby[0x4088a3] > /sbin/grubby[0x409892] > /lib64/libc.so.6(__libc_start_main+0xf4)[0x3a9561d024] > /sbin/grubby[0x402bc9] > ======= Memory map: ======== > 00400000-00442000 r-xp 00000000 09:00 11927771 /sbin/grubby > 00541000-00545000 rw-p 00041000 09:00 11927771 /sbin/grubby > 00545000-0056e000 rw-p 00545000 00:00 0 [heap] > 3a95400000-3a95419000 r-xp 00000000 09:00 8814661 /lib64/ld-2.3.90.so > 3a95519000-3a9551a000 r--p 00019000 09:00 8814661 /lib64/ld-2.3.90.so > 3a9551a000-3a9551b000 rw-p 0001a000 09:00 8814661 /lib64/ld-2.3.90.so > 3a95600000-3a95732000 r-xp 00000000 09:00 8814755 /lib64/libc-2.3.90.so > 3a95732000-3a95831000 ---p 00132000 09:00 8814755 /lib64/libc-2.3.90.so > 3a95831000-3a95835000 r--p 00131000 09:00 8814755 /lib64/libc-2.3.90.so > 3a95835000-3a95836000 rw-p 00135000 09:00 8814755 /lib64/libc-2.3.90.so > 3a95836000-3a9583b000 rw-p 3a95836000 00:00 0 > 3a97f00000-3a97f0d000 r-xp 00000000 09:00 8815104 /lib64/libgcc_s-4.1.0-20060219.so.1 > 3a97f0d000-3a9800c000 ---p 0000d000 09:00 8815104 /lib64/libgcc_s-4.1.0-20060219.so.1 > 3a9800c000-3a9800d000 rw-p 0000c000 09:00 8815104 /lib64/libgcc_s-4.1.0-20060219.so.1 > 2b0cceac9000-2b0cceaca000 rw-p 2b0cceac9000 00:00 0 > 2b0cceaf2000-2b0cceaf4000 rw-p 2b0cceaf2000 00:00 0 > 7fffffdc6000-7fffffddb000 rw-p 7fffffdc6000 00:00 0 [stack] > ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vdso] > /sbin/new-kernel-pkg: line 89: 2129 Aborted /sbin/grubby --add-kernel=$bootPrefix/$kernelName-$version $INITRD --copy-default $makedefault --title "$title" ${mbkernel:+--add-multiboot="$mbkernel"} ${mbargs:+--mbargs="$mbargs"} --args="root=$rootdevice $kernargs" --remove-kernel="TITLE=$title" > Updating : anaconda ##################### [ 23/130] > Updating : gnome-applets ##################### [ 24/130] > > > > > From mike at miketc.com Sun Feb 26 15:32:37 2006 From: mike at miketc.com (Mike Chambers) Date: Sun, 26 Feb 2006 09:32:37 -0600 Subject: rawhide report: 20060225 changes In-Reply-To: <4401C48F.20404@gmx.de> References: <200602250816.k1P8GnSl023832@porkchop.devel.redhat.com> <1140914646.7702.1.camel@xpc.home.erwinrol.com> <4401C48F.20404@gmx.de> Message-ID: <1140967957.1983.3.camel@scrappy.miketc.com> On Sun, 2006-02-26 at 16:09 +0100, Joerg Skottke wrote: > Erwin, > > same problem here, did you file an issue? Don't believe there needs to be a bug filed, as the problem is already aware of. Which is to downgrade to the next lowest mkinitrd rpm, which should be (I think) the one from FC5T3 release, until the fix is out. -- Mike Chambers Madisonville, KY "It's only funny until someone gets hurt, then it's hilarious!" From fcd-cornette at insight.rr.com Sun Feb 26 15:40:23 2006 From: fcd-cornette at insight.rr.com (Jim Cornette) Date: Sun, 26 Feb 2006 10:40:23 -0500 Subject: Fedora in need of testers? In-Reply-To: <16de708d0602252308j214295e2hfb828f5e79c7ad9f@mail.gmail.com> References: <16de708d0512222319p3307eac0k476dc2b1b0a0a061@mail.gmail.com> <200602081336.23788.lamont@gurulabs.com> <16de708d0602081359w83e1d21h6c7255aa123e5e2c@mail.gmail.com> <200602081531.49233.lamont@gurulabs.com> <16de708d0602252308j214295e2hfb828f5e79c7ad9f@mail.gmail.com> Message-ID: <4401CBE7.1080002@insight.rr.com> Arthur Pemberton wrote: > Finally have the test machine ready. However, already having problems, > the display doesn't consume the entire screen here are the specs on the > system: > > Dell - OptiPlex GX110 > Intel Pentium III Processor: 733 MHz (133MHz Bus Speed) > BIOS Version: A09 Latest version that I saw for the model on a search. > Harddrive: WDC WD200BB-75AUA1 (20 GB) > CD-ROW: Samsung CD-ROM SC-148F (48x) > Soundcard: Intel ICH82801AA > VGA: Intel 82810E DC-133 CGC > Ethernet: 3Com 3c905C-TX/TX-M [Tornado] > Monitor: Dell UltraScan P780 > > On my way to read the testers guude, have only gotten up to updating the > entire system to updates-release. > I have a computer with an Intel 815 which took the FC5T3 installation alright. There were no 640x480 or 800x600 problems that it seems you are having. Did you check the legacy video settings in BIOS? Are you trying to install the test version or FC4? My computer is a PowerSpec, but has Intel video. similar soundcard and similar Ethernet card. Jim -- Well fix that in the next (upgrade, update, patch release, service pack). From mharris at mharris.ca Sun Feb 26 17:58:25 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Sun, 26 Feb 2006 12:58:25 -0500 Subject: rawhide report: 20060226 changes In-Reply-To: <4401A8DA.9060108@hhs.nl> References: <200602260832.k1Q8W5SA014717@porkchop.devel.redhat.com> <4401A8DA.9060108@hhs.nl> Message-ID: <4401EC41.2070409@mharris.ca> Hans de Goede wrote: > > > Build System wrote: > >> >> mesa-6.4.2-5 >> ------------ >> * Sat Feb 25 2006 Mike A. Harris 6.4.2-5 >> - Disable the expeimental r300 DRI driver, as it has turned out to cause >> instability and system hangs for many users. >> > > 2 questions: > 1) disable as in not enable by default / need manual config edit to > enable, or disable as in needs recompile to enable? Disable as in, r300_dri.so is no longer included in the binary packages. > 2) if disable as in needs recompile, does it cause problems even when > turned of by default. Yes, it causes hangs on many systems, in particular X300 and higher ATI hardware even if just the dri extension module is loaded and no OpenGL software has been ran. > If not then why the disable? Because it was turned on for a short time as an experiment, with the goal being to disable it completely if there were any signs of severe instability caused by it. That instability has been observed and confirmed, so it is now disabled. > In my box the r300 drivers is one of the major features of the new X > (if and only if it works, agreed there) That is one of the reasons the experiment was tried to begin with. A number of people have requested r300 DRI support for a long time now, and finally a very highly experimental driver was created by reverse engineering. The upstream developers of the r300 driver claim straight out that it is very experimental, and not ready for mainstream use, and ATI has confirmed this as well. There are a handful of people who have installed and tried the driver and it has worked for them. The exact set of circumstances in which the driver actually works, is not fully known, and so shipping a driver that crashes or otherwise screws up one's display or locks up their system by default, is not an acceptable thing to do. Part of the experiment of including it in Fedora development was to try and gauge just how well it worked, if at all, and also to see the extent of instability it might cause. Since it /is/ experimental, the intention was always that if we did decide to ship it, DRI would be disabled by default on all of the chips it supports, requiring manual override to enable it. Unfortunately, the number of people it actually works for is very small compared to the variety of hardware it attempts to cover, and the majority of reports coming back are of the "my system is screwed" nature. Doing a bit of investigation has shown that it isn't just the r300 DRI driver that is instable, but even just loading the X server DRI module with many r300 or newer cards causes the system to crash, even if DRI is actually disabled, and even if the r300 DRI driver is not even present on the system. In order to resolve the remaining "My r300 or better class card locks up when X starts if 'Load "dri"' is present in the xorg.conf, and the problem does not go away if I use 'Option "nodri"', nor even if I delete the r300_dri.so driver, but the problem goes away if I comment 'Load "dri"' out of the config file.", it looks like we're going to have to debug what is causing the hang, and I have a good suspicion that the kernel DRM is being loaded even if DRI gets disabled, and that the kernel DRM is probably hanging the system. Hardware support that is this buggy/unstable does not belong in the OS until it is stabilized upstream *first*. I'm going to see if removal of the r300 DRM kernel module resolves the remaining problem, and if so, we might remove that too for now. The extremely small subset of users for whom this driver actually works, and is stable, are free to recompile things if they like, but with the obvious caveat that we don't support it at all, and don't support systems that have it loaded any more than we support 3rd party proprietary drivers. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From thacker at math.cornell.edu Sun Feb 26 19:14:46 2006 From: thacker at math.cornell.edu (John Thacker) Date: Sun, 26 Feb 2006 14:14:46 -0500 Subject: Fixing R300 hangs Message-ID: <20060226191446.GA5044@localhost.localdomain> Mike A. Harris wrote: > Doing a bit of investigation has shown that it isn't just the > r300 DRI driver that is instable, but even just loading the X server > DRI module with many r300 or newer cards causes the system to crash, > even if DRI is actually disabled, and even if the r300 DRI driver is > not even present on the system. I believe that this is almost surely this problem: http://lists.freedesktop.org/archives/xorg/2005-December/011678.html https://bugs.freedesktop.org/show_bug.cgi?id=4847 http://webcvs.freedesktop.org/xorg/driver/xf86-video-ati/ChangeLog?rev=1.22&view=markup There are some important memory map and other fixes for Radeon cards (especially R300 and above) that hit the xorg CVS tree on February 17, after 7.0. (The author considered them a little too experimental for 7.0.) Apparently without the fixes many people saw lockups using R300 cards without DRI enabled or the r300 DRI drive present. However, with these fixes the instability goes away. Perhaps these upstream CVS patches could be integrated into the Fedora Core patches. If so, the r300 driver could be left in FC5. Of course, we are running low on time, but I think it's a relatively critical bug. Especially if the recent Mesa change doesn't solve the crashes for everyone. John Thacker -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From gnomeuser at gmail.com Sun Feb 26 19:39:14 2006 From: gnomeuser at gmail.com (David Nielsen) Date: Sun, 26 Feb 2006 20:39:14 +0100 Subject: Fixing R300 hangs In-Reply-To: <20060226191446.GA5044@localhost.localdomain> References: <20060226191446.GA5044@localhost.localdomain> Message-ID: <1140982757.6927.4.camel@price.stavtrup-st.dk> s?n, 26 02 2006 kl. 14:14 -0500, skrev John Thacker: > Mike A. Harris wrote: > > > Doing a bit of investigation has shown that it isn't just the > > r300 DRI driver that is instable, but even just loading the X server > > DRI module with many r300 or newer cards causes the system to crash, > > even if DRI is actually disabled, and even if the r300 DRI driver is > > not even present on the system. > > I believe that this is almost surely this problem: > http://lists.freedesktop.org/archives/xorg/2005-December/011678.html > https://bugs.freedesktop.org/show_bug.cgi?id=4847 > http://webcvs.freedesktop.org/xorg/driver/xf86-video-ati/ChangeLog?rev=1.22&view=markup > > There are some important memory map and other fixes for Radeon cards > (especially R300 and above) that hit the xorg CVS tree on February > 17, after 7.0. (The author considered them a little too experimental > for 7.0.) Apparently without the fixes many people saw lockups using > R300 cards without DRI enabled or the r300 DRI drive present. However, > with these fixes the instability goes away. > > Perhaps these upstream CVS patches could be integrated into the Fedora > Core patches. If so, the r300 driver could be left in FC5. Of course, > we are running low on time, but I think it's a relatively critical bug. > Especially if the recent Mesa change doesn't solve the crashes for > everyone. Mike, could we get a set of testing rpms akin to what you did with the fonts package to see if this fixes the r300 behavioral problems? - David -- Obligatory shameless blog plug - the GNOME commentary located at: www.lovesunix.net/blog From j.w.r.degoede at hhs.nl Sun Feb 26 20:38:00 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 26 Feb 2006 21:38:00 +0100 Subject: rawhide report: 20060226 changes In-Reply-To: <4401EC41.2070409@mharris.ca> References: <200602260832.k1Q8W5SA014717@porkchop.devel.redhat.com> <4401A8DA.9060108@hhs.nl> <4401EC41.2070409@mharris.ca> Message-ID: <440211A8.5050607@hhs.nl> Mike A. Harris wrote: Taking the fact that even if disabled in software this driver causes stability problems, I fully understand the complete removal, thanks for explaining. So I agree with you except for: > > The extremely small subset of users for whom this driver actually > works, and is stable, are free to recompile things if they like, but > with the obvious caveat that we don't support it at all, and don't > support systems that have it loaded any more than we support 3rd > party proprietary drivers. > I understand the don't support part, but I have to disagree with the any more then propietary drivers, that is saying sure its open source but it really is no better then a closed driver since its reversed engineered. I agree reverse engineered is less good then based on specs, but it still beats a closed driver hands down. Especially since specs are almost always not 100% correct so driver writing is always a bit guessing / reverse engineering. Regards, Hans From pemboa at gmail.com Sun Feb 26 21:47:00 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Sun, 26 Feb 2006 15:47:00 -0600 Subject: Fedora in need of testers? In-Reply-To: <4401CBE7.1080002@insight.rr.com> References: <16de708d0512222319p3307eac0k476dc2b1b0a0a061@mail.gmail.com> <200602081336.23788.lamont@gurulabs.com> <16de708d0602081359w83e1d21h6c7255aa123e5e2c@mail.gmail.com> <200602081531.49233.lamont@gurulabs.com> <16de708d0602252308j214295e2hfb828f5e79c7ad9f@mail.gmail.com> <4401CBE7.1080002@insight.rr.com> Message-ID: <16de708d0602261347y82aa065yd1991f4f27ad3da7@mail.gmail.com> On 2/26/06, Jim Cornette wrote: > > Arthur Pemberton wrote: > > Finally have the test machine ready. However, already having problems, > > the display doesn't consume the entire screen here are the specs on the > > system: > > > > Dell - OptiPlex GX110 > > Intel Pentium III Processor: 733 MHz (133MHz Bus Speed) > > BIOS Version: A09 > Latest version that I saw for the model on a search. > > > Harddrive: WDC WD200BB-75AUA1 (20 GB) > > CD-ROW: Samsung CD-ROM SC-148F (48x) > > Soundcard: Intel ICH82801AA > > VGA: Intel 82810E DC-133 CGC > > Ethernet: 3Com 3c905C-TX/TX-M [Tornado] > > Monitor: Dell UltraScan P780 > > > > On my way to read the testers guude, have only gotten up to updating the > > entire system to updates-release. > > > > I have a computer with an Intel 815 which took the FC5T3 installation > alright. There were no 640x480 or 800x600 problems that it seems you are > having. > Did you check the legacy video settings in BIOS? I didn't specifically check for that, however, I went throught he BIOS thoroughly since I wasn't familiar with that brand of BIOS. I could have missed such a thing however. Are you trying to > install the test version or FC4? I started by install FC4 release, then yum`ed my way to updates-released, rebooted (problem remained), then yumed my way to updates-testing. My computer is a PowerSpec, but has Intel video. similar soundcard and > similar Ethernet card. I am considering a few options: 1) this is as a result of me installing FC4 over a KVM. This has causes slight monitor configuration problems before, but I was then able to fix it. 2) The drivers for this particular card are buggy. I popped in a Knoppix disk before installtion, and it too complained about the video card (somethign about incorret mode sent) and it only went up to 800x600. Just to clarfiy, I have tried various settings at and above 1024x768 they are all either badly scaled, or do not consume the screen (leaving approx. an inch top and bottom on my 19inch screen). I ensured that the montitor section in xorg.conf was as my main machine (as they share the same monitor). Should I bring this thread over to fedora-testing-list? I have since registered there. Jim > > -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From igorm5 at vip.hr Sun Feb 26 22:26:04 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Sun, 26 Feb 2006 23:26:04 +0100 Subject: Ralink rt2500, can't load module In-Reply-To: <1140834785.5730.2.camel@localhost.localdomain> References: <43FB7DC9.8060307@vip.hr> <1140834785.5730.2.camel@localhost.localdomain> Message-ID: <44022AFC.7030808@vip.hr> Dick Dishkuvek wrote: > You can fix it with my patch: > for beta3 http://dclam.com/share/param_patch_b3.txt > for cvs http://dclam.com/share/param_patch_cvs.txt > go to Modules dir and: > $ patch -p2 < ../../param_patch_b3.txt > that assumes you are using beta 3, and that the patch is two levels > down. It did help!!! Yesssss!!! Cheers mate, and thanks again!!! -- Igor Jagec From igorm5 at vip.hr Sun Feb 26 22:32:31 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Sun, 26 Feb 2006 23:32:31 +0100 Subject: Attention: Proprietary video driver users (ATI, Nvidia, etc.) In-Reply-To: <43FEDDA1.9070709@mharris.ca> References: <43FD0AC0.2090702@redhat.com> <43FD6CED.9040703@vip.hr> <43FEDDA1.9070709@mharris.ca> Message-ID: <44022C7F.4070602@vip.hr> Mike A. Harris wrote: > Using the livna ati/nvidia rpms is probably the cleanest method > currently of installing and using the proprietary drivers. Having > said that, you can still have various problems still. > Here are some off the top of my head: ... > Hope this helps. Thanks Mike, it really helped. The funny thing is that nVidia developer recommend me to use nvidia tarball instead of Livna package during the debugging of my TV out stability issue. Anyway, it (nVidia tarball) didn't solve the problem so I was lazy to bring back Livna package. Livna package also didn't provide nvidia script for debugging (they probably provide it now, I didn't check). Anyway, I'll follow your recommendations. > P.S. As always, feel free to add this info to the wiki, or paraphrase > and polish, yada yada if desired. Well, I'm sure that will do someone who speaks English as mother tongue ;) -- Igor Jagec From jorton at redhat.com Sun Feb 26 22:55:59 2006 From: jorton at redhat.com (Joe Orton) Date: Sun, 26 Feb 2006 22:55:59 +0000 Subject: httpd missing mod_access? In-Reply-To: <44019CBD.8000906@redhat.com> References: <44019CBD.8000906@redhat.com> Message-ID: <20060226225559.GA10024@redhat.com> On Sun, Feb 26, 2006 at 07:19:09AM -0500, Sam Folk-Williams wrote: > Looks like mod_access is missing from httpd in FC5T3. Am I missing > something? You're missing http://httpd.apache.org/docs/2.2/upgrading.html :) joe From sfolkwil at redhat.com Mon Feb 27 00:00:15 2006 From: sfolkwil at redhat.com (Sam Folk-Williams) Date: Sun, 26 Feb 2006 19:00:15 -0500 Subject: httpd missing mod_access? In-Reply-To: <20060226225559.GA10024@redhat.com> References: <44019CBD.8000906@redhat.com> <20060226225559.GA10024@redhat.com> Message-ID: <4402410F.9020805@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joe Orton wrote: > On Sun, Feb 26, 2006 at 07:19:09AM -0500, Sam Folk-Williams wrote: >> Looks like mod_access is missing from httpd in FC5T3. Am I missing >> something? > > You're missing http://httpd.apache.org/docs/2.2/upgrading.html :) > > joe Aha... I knew I was missing something... A lot of applications look for mod_access, notably directory server, I wonder if this name change needs to be filed as a bug against fedora-ds... Thanks! Sam -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEAkEPzOw+vBsNRroRAvAQAKCl6q3WAhBGWr3araNE/4s+WminlACfeXh/ YAjj/XNNLXcYJQGD328dUQ4= =X4l6 -----END PGP SIGNATURE----- From naheemzaffar at gmail.com Mon Feb 27 03:36:57 2006 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Mon, 27 Feb 2006 03:36:57 +0000 Subject: Fedora in need of testers? In-Reply-To: <16de708d0602261347y82aa065yd1991f4f27ad3da7@mail.gmail.com> References: <16de708d0512222319p3307eac0k476dc2b1b0a0a061@mail.gmail.com> <200602081336.23788.lamont@gurulabs.com> <16de708d0602081359w83e1d21h6c7255aa123e5e2c@mail.gmail.com> <200602081531.49233.lamont@gurulabs.com> <16de708d0602252308j214295e2hfb828f5e79c7ad9f@mail.gmail.com> <4401CBE7.1080002@insight.rr.com> <16de708d0602261347y82aa065yd1991f4f27ad3da7@mail.gmail.com> Message-ID: <3adc77210602261936o34a45ae4h454213472a6adc1a@mail.gmail.com> You probably wanted development, not updates-testing. Unless you wanted to test an update to Fedora core 4, in which case you went the right way. I would advise you to try to upgrade onto rahwide for testing the next release. There may be issues upgrading since you have gone into updates-testing. First upgrade the kernel I think. Then reboot, and do a full update... On 2/26/06, Arthur Pemberton wrote: > > > > On 2/26/06, Jim Cornette wrote: > > > > Arthur Pemberton wrote: > > > Finally have the test machine ready. However, already having problems, > > > the display doesn't consume the entire screen here are the specs on > > the > > > system: > > > > > > Dell - OptiPlex GX110 > > > Intel Pentium III Processor: 733 MHz (133MHz Bus Speed) > > > BIOS Version: A09 > > Latest version that I saw for the model on a search. > > > > > Harddrive: WDC WD200BB-75AUA1 (20 GB) > > > CD-ROW: Samsung CD-ROM SC-148F (48x) > > > Soundcard: Intel ICH82801AA > > > VGA: Intel 82810E DC-133 CGC > > > Ethernet: 3Com 3c905C-TX/TX-M [Tornado] > > > Monitor: Dell UltraScan P780 > > > > > > On my way to read the testers guude, have only gotten up to updating > > the > > > entire system to updates-release. > > > > > > > I have a computer with an Intel 815 which took the FC5T3 installation > > alright. There were no 640x480 or 800x600 problems that it seems you are > > having. > > Did you check the legacy video settings in BIOS? > > > I didn't specifically check for that, however, I went throught he BIOS > thoroughly since I wasn't familiar with that brand of BIOS. I could have > missed such a thing however. > > Are you trying to > > install the test version or FC4? > > > I started by install FC4 release, then yum`ed my way to updates-released, > rebooted (problem remained), then yumed my way to updates-testing. > > My computer is a PowerSpec, but has Intel video. similar soundcard and > > similar Ethernet card. > > > I am considering a few options: > 1) this is as a result of me installing FC4 over a KVM. This has causes > slight monitor configuration problems before, but I was then able to fix it. > > 2) The drivers for this particular card are buggy. I popped in a Knoppix > disk before installtion, and it too complained about the video card > (somethign about incorret mode sent) and it only went up to 800x600. > > Just to clarfiy, I have tried various settings at and above 1024x768 they > are all either badly scaled, or do not consume the screen (leaving approx. > an inch top and bottom on my 19inch screen). > > I ensured that the montitor section in xorg.conf was as my main machine > (as they share the same monitor). > > Should I bring this thread over to fedora-testing-list? I have since > registered there. > > Jim > > > > > -- > As a boy I jumped through Windows, as a man I play with Penguins. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From walovaton at yahoo.com.mx Sun Feb 26 14:03:03 2006 From: walovaton at yahoo.com.mx (William Lovaton) Date: Sun, 26 Feb 2006 09:03:03 -0500 Subject: Yum and SRPMs In-Reply-To: <1140421061.11256.15.camel@laurel.intra.city-fan.org> References: <1133079326.2854.1.camel@entropy> <20051128124649.GB29992@jadzia.bu.edu> <1133185654.21208.124.camel@cutter> <6280325c0511280703v2c514df8p63c31ca9cf06def7@mail.gmail.com> <1133190580.6952.0.camel@cutter> <604aa7910511280719l59f4921bja4c15e160cfb4e77@mail.gmail.com> <1133195955.16284.1.camel@weasel.turre.laiskiainen.org> <604aa7910511280856g3f043934g4c7da09e83ed181a@mail.gmail.com> <1140126778.2437.23.camel@ender> <1140274991.2211.11.camel@athlon2000> <1140421061.11256.15.camel@laurel.intra.city-fan.org> Message-ID: <1140962583.2197.1.camel@athlon2000> El lun, 20-02-2006 a las 07:37 +0000, Paul Howarth escribi??: > On Sat, 2006-02-18 at 10:03 -0500, William Lovaton wrote: > > Hi, > > > > El jue, 16-02-2006 a las 13:52 -0800, Jesse Keating escribi??: > > > I made a small mistake. The unified SRPMS and srpm repodata will be > > > useful for yumdownloader, not yum itself. Yum does not and will not > > > have the ability to grab srpms. > > > > yumdownloader? I hope it is what I am thinking. > > > > You'll see, my home computer is connected to the Internet through a > > modem and most of the time making updates is prohibited because more > > often that not they are very large, so I religiously copy the packages > > names that needs an update, I take them to my office and wget them from > > a very fast connection one by one into my usb memory and finally back to > > my home and copy the packages in the yum cache. > > > > Is there a way to make the downloading part of this automatic? something > > like yum generating all the wget commands so I can use them on a very > > fast connection easily instead of one by one. > > yumdownloader has a "--urls" option that will give you the URLs to > download. This could easily be scripted into a bunch of wget commands. > > Paul. Little question: is this a FC5 thing only? or I can get it for FC4 too? If so, where can I get it? Thanks, -William __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ?gratis! Reg?strate ya - http://correo.yahoo.com.mx/ From fcd-cornette at insight.rr.com Mon Feb 27 04:17:24 2006 From: fcd-cornette at insight.rr.com (Jim Cornette) Date: Sun, 26 Feb 2006 23:17:24 -0500 Subject: Fedora in need of testers? In-Reply-To: <16de708d0602261347y82aa065yd1991f4f27ad3da7@mail.gmail.com> References: <16de708d0512222319p3307eac0k476dc2b1b0a0a061@mail.gmail.com> <200602081336.23788.lamont@gurulabs.com> <16de708d0602081359w83e1d21h6c7255aa123e5e2c@mail.gmail.com> <200602081531.49233.lamont@gurulabs.com> <16de708d0602252308j214295e2hfb828f5e79c7ad9f@mail.gmail.com> <4401CBE7.1080002@insight.rr.com> <16de708d0602261347y82aa065yd1991f4f27ad3da7@mail.gmail.com> Message-ID: <44027D54.90005@insight.rr.com> Arthur Pemberton wrote: > > > On 2/26/06, *Jim Cornette* > wrote: > > Arthur Pemberton wrote: > > Finally have the test machine ready. However, already having > problems, > > the display doesn't consume the entire screen here are the specs > on the > > system: > > > > Dell - OptiPlex GX110 > > Intel Pentium III Processor: 733 MHz (133MHz Bus Speed) > > BIOS Version: A09 > Latest version that I saw for the model on a search. > > > Harddrive: WDC WD200BB-75AUA1 (20 GB) > > CD-ROW: Samsung CD-ROM SC-148F (48x) > > Soundcard: Intel ICH82801AA > > VGA: Intel 82810E DC-133 CGC > > Ethernet: 3Com 3c905C-TX/TX-M [Tornado] > > Monitor: Dell UltraScan P780 > > > > On my way to read the testers guude, have only gotten up to > updating the > > entire system to updates-release. > > > > I have a computer with an Intel 815 which took the FC5T3 installation > alright. There were no 640x480 or 800x600 problems that it seems you are > having. > Did you check the legacy video settings in BIOS? > > > I didn't specifically check for that, however, I went throught he BIOS > thoroughly since I wasn't familiar with that brand of BIOS. I could > have missed such a thing however. > > Are you trying to > install the test version or FC4? > > > I started by install FC4 release, then yum`ed my way to > updates-released, rebooted (problem remained), then yumed my way to > updates-testing. > > My computer is a PowerSpec, but has Intel video. similar soundcard and > similar Ethernet card. > > > I am considering a few options: > 1) this is as a result of me installing FC4 over a KVM. This has causes > slight monitor configuration problems before, but I was then able to fix it. > > 2) The drivers for this particular card are buggy. I popped in a Knoppix > disk before installtion, and it too complained about the video card > (somethign about incorret mode sent) and it only went up to 800x600. > > Just to clarfiy, I have tried various settings at and above 1024x768 > they are all either badly scaled, or do not consume the screen (leaving > approx. an inch top and bottom on my 19inch screen). > > I ensured that the montitor section in xorg.conf was as my main machine > (as they share the same monitor). > > Should I bring this thread over to fedora-testing-list? I have since > registered there. > An updated FC4 without updates-testing would qualify for resolution on fedora-list. I checked updates-testing and no xorg updates were in the repo. There are a lot of discussions in the list archives. Adding "noaccel" as an option was one listed. Personally, I found 24 for depth and 1280x1024 worked best for my purposes. I believe I adjust my monitor for vertical and horizontal sweeps not filling up the entire screen. You can adjust these settings with the menu button on most monitors. Jim -- Well fix that in the next (upgrade, update, patch release, service pack). From rje at shoreis.com Mon Feb 27 04:21:20 2006 From: rje at shoreis.com (Rob Emanuele) Date: Sun, 26 Feb 2006 20:21:20 -0800 Subject: Installation Boot Images Message-ID: <1141014080.31694.1.camel@pulsar.greatsea.com> Hi, I'd like to update the boot images like the boot.iso/pxeboot images with a newer kernel. Where can I find info on how to build those images? Thanks, Rob From dax at gurulabs.com Mon Feb 27 05:26:58 2006 From: dax at gurulabs.com (Dax Kelson) Date: Sun, 26 Feb 2006 22:26:58 -0700 Subject: dmraid and mkinitrd Message-ID: <1141018018.3592.11.camel@mentorng.gurulabs.com> In stock Fedora Core 5 test 3 with a mkinitrd-5.0.26 created initramfs the dmraid was not properly activated. I did a fresh install of FC5 test and upgraded to mkinitrd-5.0.28 inside the rescue environment. I rebuilt the initial ram disk and I'm happy to report that it fixes the problem. More details are available in the bug I filed. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182446 Dax Kelson Guru Labs From dax at gurulabs.com Mon Feb 27 05:38:49 2006 From: dax at gurulabs.com (Dax Kelson) Date: Sun, 26 Feb 2006 22:38:49 -0700 Subject: Another FC5t3/rawhide issue regarding segfaults Message-ID: <1141018729.3592.22.camel@mentorng.gurulabs.com> Hardware: AMD Athlon64 with 32bit install of FC5t3 Installed OK, booted to rescue environment with "linux rescue selinux=0" and did "yum install mkinitrd" and rebuilt initial ramdisk to fix dmraid problem. Ran through the firstboot setup and disabled SELinux, rebooted. Switched to runlevel 3 and as root ran: "yum -y update" It downloaded lots of packages, started the transaction test and Segfaulted. This was repeatable. I tried just using the rpm command to manually update the kernel. Here are the results (Is this a known problem? Worth filing?): Preparing... ########################################### [100%] 1:kernel ########################################### [100%] *** glibc detected *** /sbin/grubby: munmap_chunk(): invalid pointer: 0xbfd63d90 *** ======= Backtrace: ========= /lib/libc.so.6(__libc_free+0x17b)[0xc0a3ef] /sbin/grubby[0x804fd12] /sbin/grubby[0x804fe73] /sbin/grubby[0x8050c9e] /lib/libc.so.6(__libc_start_main+0xdc)[0xbb87a4] /sbin/grubby[0x804a001] ======= Memory map: ======== 00557000-00570000 r-xp 00000000 fd:04 5630609 /lib/ld-2.3.90.so 00570000-00571000 r-xp 00018000 fd:04 5630609 /lib/ld-2.3.90.so 00571000-00572000 rwxp 00019000 fd:04 5630609 /lib/ld-2.3.90.so 00a6b000-00a6c000 r-xp 00a6b000 00:00 0 [vdso] 00ba3000-00cc6000 r-xp 00000000 fd:04 5630616 /lib/libc-2.3.90.so 00cc6000-00cc9000 r-xp 00122000 fd:04 5630616 /lib/libc-2.3.90.so 00cc9000-00cca000 rwxp 00125000 fd:04 5630616 /lib/libc-2.3.90.so 00cca000-00ccd000 rwxp 00cca000 00:00 0 00df8000-00e03000 r-xp 00000000 fd:04 5630594 /lib/libgcc_s-4.1.0-20060214.so.1 00e03000-00e04000 rwxp 0000a000 fd:04 5630594 /lib/libgcc_s-4.1.0-20060214.so.1 08048000-08089000 r-xp 00000000 fd:04 2553628 /sbin/grubby 08089000-0808c000 rw-p 00041000 fd:04 2553628 /sbin/grubby 0808c000-08094000 rw-p 0808c000 00:00 0 0832e000-0838b000 rw-p 0832e000 00:00 0 [heap] b7f5b000-b7f5c000 rw-p b7f5b000 00:00 0 b7f66000-b7f67000 rw-p b7f66000 00:00 0 bfd51000-bfd67000 rw-p bfd51000 00:00 0 [stack] /sbin/new-kernel-pkg: line 89: 3707 Aborted /sbin/grubby --add-kernel=$bootPrefix/$kernelName-$version $INITRD --copy-default $makedefault --title "$title" ${mbkernel:+--add-multiboot="$mbkernel"} ${mbargs:+--mbargs="$mbargs"} --args="root=$rootdevice $kernargs" --remove-kernel="TITLE=$title" From davej at redhat.com Mon Feb 27 06:22:38 2006 From: davej at redhat.com (Dave Jones) Date: Mon, 27 Feb 2006 01:22:38 -0500 Subject: Another FC5t3/rawhide issue regarding segfaults In-Reply-To: <1141018729.3592.22.camel@mentorng.gurulabs.com> References: <1141018729.3592.22.camel@mentorng.gurulabs.com> Message-ID: <20060227062238.GB12955@redhat.com> On Sun, Feb 26, 2006 at 10:38:49PM -0700, Dax Kelson wrote: > Hardware: AMD Athlon64 with 32bit install of FC5t3 > > Installed OK, booted to rescue environment with "linux rescue selinux=0" > and did "yum install mkinitrd" and rebuilt initial ramdisk to fix dmraid > problem. > > Ran through the firstboot setup and disabled SELinux, rebooted. > > Switched to runlevel 3 and as root ran: > > "yum -y update" > > It downloaded lots of packages, started the transaction test and > Segfaulted. This was repeatable. > > I tried just using the rpm command to manually update the kernel. > > Here are the results (Is this a known problem? Worth filing?): known problem with mkinitrd, already filed several times. Dave From buildsys at redhat.com Mon Feb 27 08:17:21 2006 From: buildsys at redhat.com (Build System) Date: Mon, 27 Feb 2006 03:17:21 -0500 Subject: rawhide report: 20060227 changes Message-ID: <200602270817.k1R8HK4Q008251@porkchop.devel.redhat.com> Updated Packages: dasher-3.99.5-1 --------------- * Sun Feb 26 2006 Matthias Clasen - 3.99.5-1 - Update to 3.99.5 * Fri Feb 24 2006 Matthias Clasen 3.99.4-3 - Prereq: scrollkeeper * Mon Feb 20 2006 Karsten Hopp 3.99.4-2 - BuildRequires: libXtst-devel file-roller-2.13.91-2 --------------------- * Tue Feb 21 2006 Karsten Hopp 2.13.91-2 - BuildRequire: gnome-doc-utils gedit-1:2.13.92-1 ----------------- * Sun Feb 26 2006 Matthias Clasen - 2.13.92-1 - Update to 2.13.92 gnome-applets-1:2.13.90-1 ------------------------- * Sun Feb 26 2006 Matthias Clasen - 2.13.90-1 - Update to 2.13.90 gnome-power-manager-2.13.92-1 ----------------------------- * Sun Feb 26 2006 Ray Strode - 2.13.92-1 - Update to 2.13.92 gnome-speech-0.3.9-3 -------------------- * Fri Feb 24 2006 John (J5) Palmieri - 0.3.9-3 - Revert back to devel package and enable the bonobo build * Thu Feb 23 2006 John (J5) Palmieri - 0.3.9-2 - Get rid of devel package - .so now available to bonobo gtk2-2.8.13-1 ------------- * Sat Feb 25 2006 Matthias Clasen - 2.8.13-1 - Update to 2.8.13 * Fri Feb 24 2006 Ray Strode - 2.8.12-8 - add dependency on hicolor * Sat Feb 11 2006 Matthias Clasen - 2.8.12-7.1 - Update to 2.8.12 gtk2-engines-2.7.4-3 -------------------- * Sun Feb 26 2006 Matthias Clasen - 2.7.4-3 - Fix memory leaks in the Clearlooks engine mc-1:4.6.1a-8 ------------- * Sat Feb 25 2006 Jindrich Novy 4.6.1a-8 - make mc FHS compliant: store config files in /etc/mc and extfs/*.ini files in /etc/mc/extfs instead of /usr/share/mc (#2188) - the oldest open Red Hat bug is now gone ;) - fix warnings openssh-4.3p2-3 --------------- * Fri Feb 24 2006 Tomas Mraz - 4.3p2-3 - enable the subprocess in chroot to send messages to system log - sshd should prevent login if audit call fails pango-1.11.99-1 --------------- * Sun Feb 26 2006 Matthias Clasen - 1.11.99-1 - Update to 1.11.99 * Tue Feb 21 2006 Matthias Clasen - 1.11.6-1 - Upate to 1.11.6 - Drop upstreamed patches vte-0.11.20-1.fc5.1 ------------------- * Sun Feb 26 2006 Matthias Clasen 0.11.20-1 - Update to 0.11.20 Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15-5.FC5.4.i686 requires kernel = 0:2.6.15-1.1955_FC5 GFS-kernel - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5 GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5smp cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp gnbd-kernel - 2.6.15-5.FC5.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp libbtctl - 0.6.0-5.i386 requires libopenobex.so.1 struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.i386 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.i386 requires tomcat4 Broken deps for ia64 ---------------------------------------------------------- libbtctl - 0.6.0-5.ia64 requires libopenobex.so.1()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.ia64 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.ia64 requires tomcat4 vconfig - 1.9-1.1.ia64 requires libc.so.6 vconfig - 1.9-1.1.ia64 requires libc.so.6(GLIBC_2.0) Broken deps for ppc ---------------------------------------------------------- libbtctl - 0.6.0-5.ppc requires libopenobex.so.1 struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.ppc requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.ppc requires tomcat4 Broken deps for ppc64 ---------------------------------------------------------- emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi libbtctl - 0.6.0-5.ppc64 requires libopenobex.so.1()(64bit) struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.ppc64 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.ppc64 requires tomcat4 vconfig - 1.9-1.1.ppc64 requires libc.so.6 vconfig - 1.9-1.1.ppc64 requires libc.so.6(GLIBC_2.0) Broken deps for s390 ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.s390 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.s390 requires tomcat4 Broken deps for s390x ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.s390x requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.s390x requires tomcat4 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 libbtctl - 0.6.0-5.i386 requires libopenobex.so.1 libbtctl - 0.6.0-5.x86_64 requires libopenobex.so.1()(64bit) struts-webapps-tomcat3 - 1.2.8-2jpp_8fc.x86_64 requires tomcat3 struts-webapps-tomcat4 - 1.2.8-2jpp_8fc.x86_64 requires tomcat4 From che666 at gmail.com Mon Feb 27 09:12:30 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Mon, 27 Feb 2006 10:12:30 +0100 Subject: Virtual machine software for Fedora testing? In-Reply-To: <20060224153145.GY9506@redhat.com> References: <1cef3e950602231322u3c43f267k1a08290cf8755c47@mail.gmail.com> <43FE28A2.20906@cygnusx-1.org> <43FF161C.8030805@redhat.com> <1140792211.21535.32.camel@localhost.localdomain> <1140793574.27580.1.camel@ignacio.lan> <20060224153145.GY9506@redhat.com> Message-ID: 2006/2/24, Daniel Veillard : > On Fri, Feb 24, 2006 at 10:06:14AM -0500, Ignacio Vazquez-Abrams wrote: > > On Fri, 2006-02-24 at 14:43 +0000, Nigel Metheringham wrote: > > > I don't think VMware > > > does anything other than i386 running on i386 (unlike qemu). > > > > It can also do x86_64 running on x86_64, even if you're running a 32-bit > > OS. It can also do limited SMP. > > > > > Qemu would be a good extras candidate. I'm a bit surprised to see its > > > not in extras at present. > > > > It doesn't build against gcc4. > > Well technically it builds, but you get somewhat erratic runtime results :-) > > Daniel > > -- > Daniel Veillard | Red Hat 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/ > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > yup builds fine since ages with gcc 4 if you disable sparc and the compiler check. regards, Rudolf Kastl From igorm5 at vip.hr Mon Feb 27 09:25:18 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Mon, 27 Feb 2006 10:25:18 +0100 Subject: Oh no, not again beagle dep :-/ Message-ID: <4402C57E.2080005@vip.hr> Hi there! I tried to remove Evolution on fresh installed FC5 Test3 and it has Beagle dependency again :-/ There were no that problem recently, but suddenly it's also here. The second problem is NetworkManager (which is useless to me since I have static wireless IP address) which also has Evolution and Beagle dependency. [root at localhost ~]# yum remove evolution ... Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Removing: evolution i386 2.5.90-2.1 installed 29 M Removing for dependencies: beagle i386 0.2.1-12 installed 1.9 M evolution-sharp i386 0.10.2-8 installed 500 k Transaction Summary ============================================================================= Install 0 Package(s) Update 0 Package(s) Remove 3 Package(s) Is this ok [y/N]: n [root at localhost ~]# yum remove NetworkManager ... Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Removing: NetworkManager i386 0.5.1-14.cvs20060221 installed 1.0 M Removing for dependencies: NetworkManager-glib i386 0.5.1-14.cvs20060221 installed 18 k beagle i386 0.2.1-12 installed 1.9 M evolution i386 2.5.90-2.1 installed 29 M evolution-sharp i386 0.10.2-8 installed 500 k krb5-auth-dialog i386 0.6.cvs20060212-1 installed 54 k Transaction Summary ============================================================================= Install 0 Package(s) Update 0 Package(s) Remove 6 Package(s) Is this ok [y/N]: n -- Igor Jagec From emeric.maschino at jouy.inra.fr Mon Feb 27 10:46:41 2006 From: emeric.maschino at jouy.inra.fr (Emeric Maschino) Date: Mon, 27 Feb 2006 11:46:41 +0100 Subject: Fixing R300 hangs In-Reply-To: <20060226191446.GA5044@localhost.localdomain> References: <20060226191446.GA5044@localhost.localdomain> Message-ID: <1141037201.29905.18.camel@localhost.localdomain> Hi, With the patches required to prevent the hangs, is DRI working fine for you? As I previously reported (cf. DRI permission problem in this list), I'm getting "Operation not permitted" when trying to use DRI and libGL reverts back to (slow) indirect rendering with my ATI FireGL X1 (9700 chipset, r300 driver). Cheers, ?meric > Mike A. Harris wrote: > > > Doing a bit of investigation has shown that it isn't just the > > r300 DRI driver that is instable, but even just loading the X server > > DRI module with many r300 or newer cards causes the system to crash, > > even if DRI is actually disabled, and even if the r300 DRI driver is > > not even present on the system. > > I believe that this is almost surely this problem: > http://lists.freedesktop.org/archives/xorg/2005-December/011678.html > https://bugs.freedesktop.org/show_bug.cgi?id=4847 > http://webcvs.freedesktop.org/xorg/driver/xf86-video-ati/ChangeLog?rev=1.22&view=markup > > There are some important memory map and other fixes for Radeon cards > (especially R300 and above) that hit the xorg CVS tree on February > 17, after 7.0. (The author considered them a little too experimental > for 7.0.) Apparently without the fixes many people saw lockups using > R300 cards without DRI enabled or the r300 DRI drive present. However, > with these fixes the instability goes away. > > Perhaps these upstream CVS patches could be integrated into the Fedora > Core patches. If so, the r300 driver could be left in FC5. Of course, > we are running low on time, but I think it's a relatively critical bug. > Especially if the recent Mesa change doesn't solve the crashes for > everyone. > > John Thacker > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From camilo at mesias.co.uk Mon Feb 27 11:24:34 2006 From: camilo at mesias.co.uk (Cam) Date: Mon, 27 Feb 2006 11:24:34 +0000 Subject: Fixing R300 hangs In-Reply-To: <1141037201.29905.18.camel@localhost.localdomain> References: <20060226191446.GA5044@localhost.localdomain> <1141037201.29905.18.camel@localhost.localdomain> Message-ID: <4402E172.2090200@mesias.co.uk> Emeric, list I was wondering if there was a set of rpms anywhere for testing (I have a machine with ati / radeon hangs, Bug 175263, Bug 182196). If not, I can see the patch (http://ucw.dustbite.net/xorg/xf86-video-ati-6.5.7.2-radeon_memmap_fix.patch.gz), and the SPRMS (http://download.fedora.redhat.com/pub/fedora/linux/core/test/4.92/source/SRPMS/) Which rpms would need to be patched, I'm guessing at least xorg-x11-drv-ati but maybe whatever provides the kernel module, and mesa would need to be a different version? Any ideas or should I just wait? -Cam -- camilo at mesias.co.uk <-- From paul at city-fan.org Mon Feb 27 12:04:22 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 27 Feb 2006 12:04:22 +0000 Subject: Yum and SRPMs In-Reply-To: <1140962583.2197.1.camel@athlon2000> References: <1133079326.2854.1.camel@entropy> <20051128124649.GB29992@jadzia.bu.edu> <1133185654.21208.124.camel@cutter> <6280325c0511280703v2c514df8p63c31ca9cf06def7@mail.gmail.com> <1133190580.6952.0.camel@cutter> <604aa7910511280719l59f4921bja4c15e160cfb4e77@mail.gmail.com> <1133195955.16284.1.camel@weasel.turre.laiskiainen.org> <604aa7910511280856g3f043934g4c7da09e83ed181a@mail.gmail.com> <1140126778.2437.23.camel@ender> <1140274991.2211.11.camel@athlon2000> <1140421061.11256.15.camel@laurel.intra.city-fan.org> <1140962583.2197.1.camel@athlon2000> Message-ID: <4402EAC6.9040805@city-fan.org> William Lovaton wrote: > El lun, 20-02-2006 a las 07:37 +0000, Paul Howarth escribi?: > >>On Sat, 2006-02-18 at 10:03 -0500, William Lovaton wrote: >> >>>Hi, >>> >>>El jue, 16-02-2006 a las 13:52 -0800, Jesse Keating escribi?: >>> >>>>I made a small mistake. The unified SRPMS and srpm repodata will be >>>>useful for yumdownloader, not yum itself. Yum does not and will not >>>>have the ability to grab srpms. >>> >>>yumdownloader? I hope it is what I am thinking. >>> >>>You'll see, my home computer is connected to the Internet through a >>>modem and most of the time making updates is prohibited because more >>>often that not they are very large, so I religiously copy the packages >>>names that needs an update, I take them to my office and wget them from >>>a very fast connection one by one into my usb memory and finally back to >>>my home and copy the packages in the yum cache. >>> >>>Is there a way to make the downloading part of this automatic? something >>>like yum generating all the wget commands so I can use them on a very >>>fast connection easily instead of one by one. >> >>yumdownloader has a "--urls" option that will give you the URLs to >>download. This could easily be scripted into a bunch of wget commands. >> >>Paul. > > > Little question: is this a FC5 thing only? or I can get it for FC4 too? > If so, where can I get it? yumdownloader is part of the yum-utils package, which is available in Extras for FC4. Paul. From mharris at mharris.ca Mon Feb 27 12:11:34 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 27 Feb 2006 07:11:34 -0500 Subject: Fixing R300 hangs In-Reply-To: <20060226191446.GA5044@localhost.localdomain> References: <20060226191446.GA5044@localhost.localdomain> Message-ID: <4402EC76.3070900@mharris.ca> John Thacker wrote: > Mike A. Harris wrote: > > >>Doing a bit of investigation has shown that it isn't just the >>r300 DRI driver that is instable, but even just loading the X server >>DRI module with many r300 or newer cards causes the system to crash, >>even if DRI is actually disabled, and even if the r300 DRI driver is >>not even present on the system. > > > I believe that this is almost surely this problem: > http://lists.freedesktop.org/archives/xorg/2005-December/011678.html > https://bugs.freedesktop.org/show_bug.cgi?id=4847 > http://webcvs.freedesktop.org/xorg/driver/xf86-video-ati/ChangeLog?rev=1.22&view=markup > > There are some important memory map and other fixes for Radeon cards > (especially R300 and above) that hit the xorg CVS tree on February > 17, after 7.0. (The author considered them a little too experimental > for 7.0.) Apparently without the fixes many people saw lockups using > R300 cards without DRI enabled or the r300 DRI drive present. However, > with these fixes the instability goes away. > > Perhaps these upstream CVS patches could be integrated into the Fedora > Core patches. The great thing about modular X, is that it makes it possible for X.Org to release new versions of individual components much more easily. This means that problems of this nature which get fixed, can be integrated into the next stable bugfix release of the particular component. Any patches that get committed to the CVS head of any given component in X.Org, show commitment that they'll be present in the next major release of the X Window System - 7.1. If the upstream developers feel confident about a particular patch being stable for the existing release, they can commit it to the stable branch of the particular component and release an update of that specific component, without having to release the entire window system. Once upstream has integrated the patches into the stable branch, and has released an updated set of packages with the fixes present, we will consider releasing a Fedora Core 5 update to the new packages. > If so, the r300 driver could be left in FC5. Of course, > we are running low on time, but I think it's a relatively critical bug. > Especially if the recent Mesa change doesn't solve the crashes for > everyone. My current plan for the r300 dri driver, is to leave it out of FC5, and once the various issues are resolved upstream we will re-enable it in rawhide post-FC5. This will allow the driver to get the level of testing that is needed, and hopefully to stabilize sooner. Then, once the major problems are resolved upstream by X.Org/DRI developers, and new upstream stable packages have been released with the fixes, we will probably include them in rawhide. If the r300 DRI support matures upstream enough that it is not going to be a major support burden, then we will consider enabling it in a future FC5 update. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Mon Feb 27 12:23:15 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 27 Feb 2006 07:23:15 -0500 Subject: Fixing R300 hangs In-Reply-To: <1140982757.6927.4.camel@price.stavtrup-st.dk> References: <20060226191446.GA5044@localhost.localdomain> <1140982757.6927.4.camel@price.stavtrup-st.dk> Message-ID: <4402EF33.30609@mharris.ca> David Nielsen wrote: > s?n, 26 02 2006 kl. 14:14 -0500, skrev John Thacker: > >>Mike A. Harris wrote: >> >> >>>Doing a bit of investigation has shown that it isn't just the >>>r300 DRI driver that is instable, but even just loading the X server >>>DRI module with many r300 or newer cards causes the system to crash, >>>even if DRI is actually disabled, and even if the r300 DRI driver is >>>not even present on the system. >> >>I believe that this is almost surely this problem: >>http://lists.freedesktop.org/archives/xorg/2005-December/011678.html >>https://bugs.freedesktop.org/show_bug.cgi?id=4847 >>http://webcvs.freedesktop.org/xorg/driver/xf86-video-ati/ChangeLog?rev=1.22&view=markup >> >>There are some important memory map and other fixes for Radeon cards >>(especially R300 and above) that hit the xorg CVS tree on February >>17, after 7.0. (The author considered them a little too experimental >>for 7.0.) Apparently without the fixes many people saw lockups using >>R300 cards without DRI enabled or the r300 DRI drive present. However, >>with these fixes the instability goes away. >> >>Perhaps these upstream CVS patches could be integrated into the Fedora >>Core patches. If so, the r300 driver could be left in FC5. Of course, >>we are running low on time, but I think it's a relatively critical bug. >>Especially if the recent Mesa change doesn't solve the crashes for >>everyone. > > Mike, could we get a set of testing rpms akin to what you did with the > fonts package to see if this fixes the r300 behavioral problems? Sure, check the Xorg sources/spec out of Fedora CVS, snag the patches from upstream CVS with cvs rdiff, apply them to the package, appending a custom identifier to the Release field such as: .dnielsen.1 to distinguish it from official Red Hat packaging, build new rpms and upload them to a custom yum repository. Might want to call it something like "David's Experimental X.org" or something to distinguish it. That would provide a useful resource for the various people who would like to volunteer to help test and stabilize the r300 DRI support. It would also be a good idea to join the #dri-devel and #xorg-devel IRC channels on freenode, where most of the core developers frequent. That can be useful for realtime debugging discussion, etc. Another channel is #fedora-x, which I've been using for Fedora specific development/ packaging/maintenance discussion, but the other 2 channels are more useful for general issues. Once you've got rpms ready, my recommendation would be to post an email to announce them to fedora-devel-list, fedora-test-list, and the main X.Org mailing list - xorg at lists.freedesktop.org It's good to see more and more people volunteering to help out the X.Org project like this! It sure confirms the X.Org bazaar style development model was the right direction, over the closed development model of the previous X Window System implementation that was commonly shipped in the past. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Mon Feb 27 12:34:27 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 27 Feb 2006 07:34:27 -0500 Subject: rawhide report: 20060226 changes In-Reply-To: <440211A8.5050607@hhs.nl> References: <200602260832.k1Q8W5SA014717@porkchop.devel.redhat.com> <4401A8DA.9060108@hhs.nl> <4401EC41.2070409@mharris.ca> <440211A8.5050607@hhs.nl> Message-ID: <4402F1D3.9080502@mharris.ca> Hans de Goede wrote: >> The extremely small subset of users for whom this driver actually >> works, and is stable, are free to recompile things if they like, but >> with the obvious caveat that we don't support it at all, and don't >> support systems that have it loaded any more than we support 3rd >> party proprietary drivers. > > I understand the don't support part, but I have to disagree with the any > more then propietary drivers, You can disagree with me all you like, but we have never supported software that does not ship with the OS. That includes open source kernel modules, X drivers, or any other software. People using drivers that do not ship with the OS, take full responsibility for any problems they may encounter doing so. In particular for kernel modules and X drivers, both of which can cause complete system hangs. By all means, feel free to install/use whatever drivers you like, but if they break, and we didn't ship them - you get to keep both pieces, wether they are open source or not. > that is saying sure its open source but it really is no better then > a closed driver since its reversed engineered. That's your personal thoughts, not mine. My claim is essentially: "if we don't ship it, we don't provide maintenance it, wether it is open source or not period." If you have a driver installed/loaded in your system which we do not support, and you have a system hang, you'll need to reproduce the hang with the unsupported driver removed before we touch the issue. This is not something new. It's been like this from the beginning of time, I am only restating it to make sure people are fully aware of it. > I agree reverse engineered is less good then based on specs, but it > still beats a closed driver hands down. That depends on your perspective I guess. An open source driver is better than a closed source one from an OSS advocacy perspective, and that is where my personal ideologies are. However many people would argue with you that "a functional driver that allows me to use all of the features of my hardware and actually works" is a better driver, regardless of wether it is open source or closed source. The fact is, each individual person has different needs/requirements, and different ideologies of "what is better". I strongly prefer open source drivers over proprietary ones - to the point where I have never installed any of the proprietary drivers on my systems. So in that regard I agree with you. Having said that, an open source driver that is non-functional or which locks up most people's systems is not particularly what I would call "better" in any sense. At least not until the people developing it get it into a useable and reliable state anyway. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From dhollis at davehollis.com Mon Feb 27 14:42:42 2006 From: dhollis at davehollis.com (David Hollis) Date: Mon, 27 Feb 2006 09:42:42 -0500 Subject: httpd missing mod_access? In-Reply-To: <4402410F.9020805@redhat.com> References: <44019CBD.8000906@redhat.com> <20060226225559.GA10024@redhat.com> <4402410F.9020805@redhat.com> Message-ID: <1141051362.2440.2.camel@dhollis-lnx.sunera.com> On Sun, 2006-02-26 at 19:00 -0500, Sam Folk-Williams wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Joe Orton wrote: > > On Sun, Feb 26, 2006 at 07:19:09AM -0500, Sam Folk-Williams wrote: > >> Looks like mod_access is missing from httpd in FC5T3. Am I missing > >> something? > > > > You're missing http://httpd.apache.org/docs/2.2/upgrading.html :) > > > > joe > Aha... I knew I was missing something... A lot of applications look for > mod_access, notably directory server, I wonder if this name change needs > to be filed as a bug against fedora-ds... It would be a bug against FDS (imho). Apache isn't broken by changing/removing mod_access. FDS will need to have some type of compatibility logic to handle Apache < 2.2 and Apache >= 2.2 installations appropriately. -- David Hollis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From thacker at math.cornell.edu Mon Feb 27 15:48:37 2006 From: thacker at math.cornell.edu (John Thacker) Date: Mon, 27 Feb 2006 10:48:37 -0500 Subject: Fixing R300 hangs In-Reply-To: <4402EC76.3070900@mharris.ca> References: <20060226191446.GA5044@localhost.localdomain> <4402EC76.3070900@mharris.ca> Message-ID: <20060227154837.GA18097@localhost.localdomain> On Mon, Feb 27, 2006 at 07:11:34AM -0500, Mike A. Harris wrote: > My current plan for the r300 dri driver, is to leave it out of FC5, and > once the various issues are resolved upstream we will re-enable it in > rawhide post-FC5. This will allow the driver to get the level of > testing that is needed, and hopefully to stabilize sooner. Then, once > the major problems are resolved upstream by X.Org/DRI developers, and > new upstream stable packages have been released with the fixes, we will > probably include them in rawhide. Sounds decent. I'd be extremely reluctant to update FC5 to something that's only in CVS. The only reason for suggesting it is that it seemed like you were saying that some people were seeing lockups even with the r300 dri driver from Mesa not even present on their system. Maybe I misread it, but if it turns out that there's no other way to prevent hangs on r300-based cards then the CVS patches should perhaps be considered. Note that some of the bug reports claim that even without DRI lockups occur from using the framebuffer device, and that a lot of the patches apply to the main radeon X driver rather than dri. I don't know if removing the dri driver is enough to fix it. Hopefully so. John Thacker -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From dhollis at davehollis.com Mon Feb 27 14:42:42 2006 From: dhollis at davehollis.com (David Hollis) Date: Mon, 27 Feb 2006 09:42:42 -0500 Subject: httpd missing mod_access? In-Reply-To: <4402410F.9020805@redhat.com> References: <44019CBD.8000906@redhat.com> <20060226225559.GA10024@redhat.com> <4402410F.9020805@redhat.com> Message-ID: <1141051362.2440.2.camel@dhollis-lnx.sunera.com> On Sun, 2006-02-26 at 19:00 -0500, Sam Folk-Williams wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Joe Orton wrote: > > On Sun, Feb 26, 2006 at 07:19:09AM -0500, Sam Folk-Williams wrote: > >> Looks like mod_access is missing from httpd in FC5T3. Am I missing > >> something? > > > > You're missing http://httpd.apache.org/docs/2.2/upgrading.html :) > > > > joe > Aha... I knew I was missing something... A lot of applications look for > mod_access, notably directory server, I wonder if this name change needs > to be filed as a bug against fedora-ds... It would be a bug against FDS (imho). Apache isn't broken by changing/removing mod_access. FDS will need to have some type of compatibility logic to handle Apache < 2.2 and Apache >= 2.2 installations appropriately. -- David Hollis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From jkeating at j2solutions.net Mon Feb 27 17:05:04 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 27 Feb 2006 09:05:04 -0800 Subject: Oh no, not again beagle dep :-/ In-Reply-To: <4402C57E.2080005@vip.hr> References: <4402C57E.2080005@vip.hr> Message-ID: <1141059905.21520.28.camel@ender> On Mon, 2006-02-27 at 10:25 +0100, Igor Jagec wrote: > I tried to remove Evolution on fresh installed FC5 Test3 and it has > Beagle dependency again :-/ There were no that problem recently, but > suddenly it's also here. The second problem is NetworkManager (which is > useless to me since I have static wireless IP address) which also has > Evolution and Beagle dependency. These have deps on evolution-sharp, not evolution itself. Unfortunately something happened to make evolution-sharp depend on evolution. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Mon Feb 27 17:13:56 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Feb 2006 12:13:56 -0500 Subject: gphoto2 problem: usb access for non root users In-Reply-To: <200602241919.34962.jbarnes@virtuousgeek.org> References: <561c252c0601311402s2dfa06d3s@mail.gmail.com> <200602241919.34962.jbarnes@virtuousgeek.org> Message-ID: <20060227171355.GA31836@devserv.devel.redhat.com> Jesse Barnes (jbarnes at virtuousgeek.org) said: > Hm, I haven't been so lucky. When I plugin my camera, I get a popup > under KDE asking me if I want to open a window. If I select 'yes' the > window comes up but times out saying it couldn't claim the usb device, > presumably because both /proc/bus/usb and /dev/bus/usb are owned > completely by root. My /usr/libexec/gphoto-udev-thunk-set-my-perms > script has the right lines to set the perms, but maybe HAL isn't > setting the right env. vars for it when it's called? What hal, udev, and libusb do you have? Bill From jbarnes at virtuousgeek.org Mon Feb 27 17:45:03 2006 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Mon, 27 Feb 2006 09:45:03 -0800 Subject: gphoto2 problem: usb access for non root users In-Reply-To: <20060227171355.GA31836@devserv.devel.redhat.com> References: <561c252c0601311402s2dfa06d3s@mail.gmail.com> <200602241919.34962.jbarnes@virtuousgeek.org> <20060227171355.GA31836@devserv.devel.redhat.com> Message-ID: <200602270945.03846.jbarnes@virtuousgeek.org> On Monday, February 27, 2006 9:13 am, Bill Nottingham wrote: > Jesse Barnes (jbarnes at virtuousgeek.org) said: > > Hm, I haven't been so lucky. When I plugin my camera, I get a popup > > under KDE asking me if I want to open a window. If I select 'yes' > > the window comes up but times out saying it couldn't claim the usb > > device, presumably because both /proc/bus/usb and /dev/bus/usb are > > owned completely by root. My > > /usr/libexec/gphoto-udev-thunk-set-my-perms script has the right > > lines to set the perms, but maybe HAL isn't setting the right env. > > vars for it when it's called? > > What hal, udev, and libusb do you have? The latest rawhide bits as of Saturday (sorry can't check them directly right now). I've tried several reboots and changes of init levels since that seemed to work for Gianluca, but no dice. If I wanted to add some additional echo statements to the /usr/libexec/gphoto-set-procperm where would their output show up? I wanted to check and see if the environment variables were getting set correctly, since everything else looks ok (guess I can just redirect to a file to do some debugging, I'll try that when I get home). Thanks, Jesse From notting at redhat.com Mon Feb 27 17:48:48 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Feb 2006 12:48:48 -0500 Subject: gphoto2 problem: usb access for non root users In-Reply-To: <200602270945.03846.jbarnes@virtuousgeek.org> References: <561c252c0601311402s2dfa06d3s@mail.gmail.com> <200602241919.34962.jbarnes@virtuousgeek.org> <20060227171355.GA31836@devserv.devel.redhat.com> <200602270945.03846.jbarnes@virtuousgeek.org> Message-ID: <20060227174848.GB9529@devserv.devel.redhat.com> Jesse Barnes (jbarnes at virtuousgeek.org) said: > If I wanted to add some additional echo statements to > the /usr/libexec/gphoto-set-procperm where would their output show up? > I wanted to check and see if the environment variables were getting set > correctly, since everything else looks ok (guess I can just redirect to > a file to do some debugging, I'll try that when I get home). set > /tmp/gphoto.$$ should be simple enough for debugging. Bill From thacker at math.cornell.edu Mon Feb 27 18:07:35 2006 From: thacker at math.cornell.edu (John Thacker) Date: Mon, 27 Feb 2006 13:07:35 -0500 Subject: udev brokenness with multiple CDROMS Message-ID: <20060227180735.GA3043@localhost.localdomain> I know that udev removed mention of %e (the enumeration flag that creates /dev/cdrom, /dev/cdrom1, etc) from its man page, but I thought that it still worked. However, it's not working for me. I have a DVD+/-RW and a CD-RW. udev is apparently trying to map both of them to just /dev/cdrom, and only one symlink gets created. (It does sometimes change which one gets the link upon reboot.) This is particularly annoying since the PAM magic in /etc/security/console.perms requires the /dev/cdrom* files to exist for each drive in order for the console permissions to be properly set upon login. Should /etc/udev/rules.d/50-udev.rules be changed somehow to use something other than %e to get this to work? Output of udevinfo, showing both devices with the same symlinks in the udev database: [root at localhost dev]# udevinfo -q all -n /dev/hdc P: /block/hdc N: hdc S: cdrom S: dvd S: cdwriter S: dvdwriter S: disk/by-path/pci-0000:00:09.0-ide-1:0 E: ID_TYPE=cd E: ID_MODEL=_NEC_DVD_RW_ND-3520A E: ID_SERIAL= E: ID_REVISION=1.04 E: ID_BUS=ata E: ID_PATH=pci-0000:00:09.0-ide-1:0 [root at localhost dev]# udevinfo -q all -n /dev/hdd P: /block/hdd N: hdd S: cdrom S: cdwriter S: disk/by-path/pci-0000:00:09.0-ide-1:1 E: ID_TYPE=cd E: ID_MODEL=LITE-ON_LTR-24102B E: ID_SERIAL= E: ID_REVISION=5S5A E: ID_BUS=ata E: ID_PATH=pci-0000:00:09.0-ide-1:1 [root at localhost dev]# udevinfo -q all -n /dev/cdrom P: /block/hdd N: hdd S: cdrom S: cdwriter S: disk/by-path/pci-0000:00:09.0-ide-1:1 E: ID_TYPE=cd E: ID_MODEL=LITE-ON_LTR-24102B E: ID_SERIAL= E: ID_REVISION=5S5A E: ID_BUS=ata E: ID_PATH=pci-0000:00:09.0-ide-1:1 John Thacker -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From Liste at famillecollet.com Mon Feb 27 18:06:21 2006 From: Liste at famillecollet.com (Remi Collet) Date: Mon, 27 Feb 2006 19:06:21 +0100 Subject: need help with hal under FC5t3 Message-ID: <44033F9D.2010604@FamilleCollet.com> I use a external firewire disk to store a lot of data. Under FC4, it was mounted on "hotplug" using the line present in /etc/fstab (to force the mount point and the UTF8 option). I'm also used to add a hal policy tu add the UTF8 option (for my USB sticks). With FC5, the /usr/share/hal/scripts/hal-system-storage-mount detect the line in /etc/fstab and deny the mount. Questions are - how can i choose the mount point (outside the /media dir) - how can i choose the UTF8 option (the old solution "volume.policy.mount_option.iocharset=utf8" doesn't work) Thanks for your help. Remi From wtogami at redhat.com Mon Feb 27 18:59:28 2006 From: wtogami at redhat.com (Warren Togami) Date: Mon, 27 Feb 2006 13:59:28 -0500 Subject: Test: Rawhide kernel install crash, SMP crash Message-ID: <44034C10.4040509@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183010 Rawhide has been suffering since Friday a crash during kernel installation in "grubby" which causes a failure to add the kernel to grub.conf. http://people.redhat.com/wtogami/temp/rawhide/ I copied new mkinitrd (plus sources) for people suffering from this issue in order to workaround these problems earlier than tonight's rawhide push. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182731 SMP kernel crash http://people.redhat.com/davej/kernels/Fedora/devel/ Get 1990+ kernel from here, or wait until tonight's rawhide push. Do not reply here if you see problems, please use Bugzilla. Warren Togami wtogami at redhat.com From rje at shoreis.com Mon Feb 27 19:23:31 2006 From: rje at shoreis.com (Rob Emanuele) Date: Mon, 27 Feb 2006 11:23:31 -0800 Subject: Rebuilding a Fedora Core Installation Boot Image Message-ID: <1141068211.31694.3.camel@pulsar.greatsea.com> Hi, I'd like to update the boot images like the boot.iso/pxeboot images with a newer kernel. Where can I find info on how to build those images? Thanks, Rob From kwade at redhat.com Mon Feb 27 19:31:54 2006 From: kwade at redhat.com (Karsten Wade) Date: Mon, 27 Feb 2006 11:31:54 -0800 Subject: [ANN] Last call for release notes to go into ISO Message-ID: <1141068714.17062.58.camel@erato.phig.org> We are in the final four hours before freezing the release notes content from the Wiki to move it out for translation. There is still a 08 March 2006 deadline for content that goes into the Web-published latest notes. You can review your area(s) of interest here: http://fedoraproject.org/wiki/Docs/Beats Edit the Wiki directly. Drop by #fedora-websites if you have any problems getting your account working again, remember that you need to have signed your CLA before you can be in the EditGroup (again). Thanks - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- A non-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 Mon Feb 27 20:15:23 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 27 Feb 2006 15:15:23 -0500 Subject: Oh no, not again beagle dep :-/ In-Reply-To: <1141059905.21520.28.camel@ender> References: <4402C57E.2080005@vip.hr> <1141059905.21520.28.camel@ender> Message-ID: <604aa7910602271215n2080487ax821ec9816acc3496@mail.gmail.com> On 2/27/06, Jesse Keating wrote: > These have deps on evolution-sharp, not evolution itself. Unfortunately > something happened to make evolution-sharp depend on evolution. That something would be libeshell rpm -q --requires evolution-sharp |grep libeshell libeshell.so.0 rpm -q --whatprovides libeshell.so.0 evolution-2.5.90-2.1 And evolution has a dep on NetworkManager through a depchain involving libnm_glib.so.0...without invoking the evo-sharp issue above. rpm -q --requires evolution|grep libnm libnm_glib.so.0 rpm -q --whatprovides libnm_glib.so.0 NetworkManager-glib-0.5.1-14.cvs20060221 rpm -q --requires NetworkManager-glib NetworkManager = 0.5.1-14.cvs20060221 rpm -q --whatprovides NetworkManager NetworkManager-0.5.1-14.cvs20060221 I'm not even sure what feature of evolution integrates with NM to pull in libnm_glib.so.0. One of the non-optional evolution "plugins" perhaps? -jef From mharris at mharris.ca Mon Feb 27 21:05:53 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 27 Feb 2006 16:05:53 -0500 Subject: Fixing R300 hangs In-Reply-To: <20060227154837.GA18097@localhost.localdomain> References: <20060226191446.GA5044@localhost.localdomain> <4402EC76.3070900@mharris.ca> <20060227154837.GA18097@localhost.localdomain> Message-ID: <440369B1.2040901@mharris.ca> John Thacker wrote: > On Mon, Feb 27, 2006 at 07:11:34AM -0500, Mike A. Harris wrote: > >>My current plan for the r300 dri driver, is to leave it out of FC5, and >>once the various issues are resolved upstream we will re-enable it in >>rawhide post-FC5. This will allow the driver to get the level of >>testing that is needed, and hopefully to stabilize sooner. Then, once >>the major problems are resolved upstream by X.Org/DRI developers, and >>new upstream stable packages have been released with the fixes, we will >>probably include them in rawhide. > > > Sounds decent. I'd be extremely reluctant to update FC5 to something > that's only in CVS. The only reason for suggesting it is that it seemed > like you were saying that some people were seeing lockups even with > the r300 dri driver from Mesa not even present on their system. Maybe > I misread it, but if it turns out that there's no other way to prevent > hangs on r300-based cards then the CVS patches should perhaps be considered. There are multiple different problems, rather than a single problem. Some users experience lockups or otherwise non-working X without the r300_dri driver present. That issue is still there, and hopefully can be diagnosed and fixed for FC5. With the r300_dri driver installed, users who do not experience the above problem (or problems - there are many reports, and it may be multiple bugs), may still have hangs wether or not the "Load "dri"" is present or not, and wether or not "Option "nodri"" is specified. If none of these problems happen, and no other non-3D related hang kills a person's system, then it is just a crapshoot wether DRI enabled operation will work on a given R300 or higher card with the driver present, and what magic incantations might be needed to get it to work on a given motherboard. All and all, R300+ support is quite shaky right now, both 3D and 2D, so it is a process of reducing the instability by removing variables, and then over time resolving issues one at a time. The priority for FC5 is to get as many people's systems in "X starts and I can surf the web" state. Anything on top of that is icing on the cake, and bonus-plan material. If we can get to that state, there will be far fewer incoming bug reports when FC5 goes out the door, giving us much more time to spend fixing bugs rather than triaging mass bug duplicates. > Note that some of the bug reports claim that even without DRI lockups > occur from using the framebuffer device, and that a lot of the patches > apply to the main radeon X driver rather than dri. I don't know if > removing the dri driver is enough to fix it. Hopefully so. Exactly. There is no "it". There are numerous bugs occuring, some of which might even be kernel related. Removing the dri driver, removes incoming bug reports related to people who are trying to use the DRI driver, when it is known to be unstable and experimental by definition, allowing us to concentrate on bugs that are occuring with the non-experimental code. Anyway, it's a done deal. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From jkeating at j2solutions.net Mon Feb 27 21:19:13 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 27 Feb 2006 13:19:13 -0800 Subject: Oh no, not again beagle dep :-/ In-Reply-To: <604aa7910602271215n2080487ax821ec9816acc3496@mail.gmail.com> References: <4402C57E.2080005@vip.hr> <1141059905.21520.28.camel@ender> <604aa7910602271215n2080487ax821ec9816acc3496@mail.gmail.com> Message-ID: <1141075153.21520.60.camel@ender> On Mon, 2006-02-27 at 15:15 -0500, Jeff Spaleta wrote: > > I'm not even sure what feature of evolution integrates with NM to pull > in libnm_glib.so.0. One of the non-optional evolution "plugins" > perhaps? Yes, when nm detects network failure or disconnect, evolution will disconnect as well to prevent error messages from popping up. Not that this works or anything, I still get error windows from Evo even though I've put it in offline state. Conversely when NM reconnects, evo will reconnect to. Highly frustrating for those of us that require VPN connection before email will flow. I really wish I could disable it and manage my email connection myself. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Mon Feb 27 21:20:08 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 27 Feb 2006 15:20:08 -0600 Subject: Rebuilding a Fedora Core Installation Boot Image In-Reply-To: <1141068211.31694.3.camel@pulsar.greatsea.com> (Rob Emanuele's message of "Mon, 27 Feb 2006 11:23:31 -0800") References: <1141068211.31694.3.camel@pulsar.greatsea.com> Message-ID: >>>>> "RE" == Rob Emanuele writes: RE> Where can I find info on how to build those images? Search for "buildinstall". Basically, install anaconda and anaconda-runtime, copy your complete updated tree[1] to a writable directory (I used /tmp/a), make sure you have a pkgorder file and run something like: /usr/lib/anaconda-runtime/buildinstall --debug --comp blah --pkgorder /tmp/a/pkgorder --version 4 --product Fedora --release "Fedora Core 4" --prodpath Fedora /tmp/a which, if everything works, will grind for a bit and then spit out a rebuilt set of images. I recently had to do this to support the hardware on some systems with nForce4 430-based boards. (I had to apply a couple of quick hacks to anaconda and kudzu as well; see the anaconda-devel archives for details. 1) I have a script (pilfered from elsewhere on the 'net) that will pull updates into a tree and regenerate hdlist for you. As a bonus it spits out a pkgorder file as well. If you want it, let me know and I'll put it somewhere accessible. - J< From k.georgiou at imperial.ac.uk Mon Feb 27 21:45:03 2006 From: k.georgiou at imperial.ac.uk (Kostas Georgiou) Date: Mon, 27 Feb 2006 21:45:03 +0000 Subject: gphoto2 problem: usb access for non root users In-Reply-To: <20060227174848.GB9529@devserv.devel.redhat.com> References: <561c252c0601311402s2dfa06d3s@mail.gmail.com> <200602241919.34962.jbarnes@virtuousgeek.org> <20060227171355.GA31836@devserv.devel.redhat.com> <200602270945.03846.jbarnes@virtuousgeek.org> <20060227174848.GB9529@devserv.devel.redhat.com> Message-ID: <20060227214503.GA5902@imperial.ac.uk> On Mon, Feb 27, 2006 at 12:48:48PM -0500, Bill Nottingham wrote: > Jesse Barnes (jbarnes at virtuousgeek.org) said: > > If I wanted to add some additional echo statements to > > the /usr/libexec/gphoto-set-procperm where would their output show up? > > I wanted to check and see if the environment variables were getting set > > correctly, since everything else looks ok (guess I can just redirect to > > a file to do some debugging, I'll try that when I get home). > > set > /tmp/gphoto.$$ should be simple enough for debugging. Well since I am home "chown $console_user /dev/bus/usb/$bus_num/$dev_num" fails with: chown: cannot access `/dev/bus/usb/002/018': No such file or directory Anything that slows down the script (ls /dev/bus/usb/$bus_num, usleep 1, etc.) seems to be enough for the device to be created. Should the script wait for the device to be created or is there a better way to handle this? From notting at redhat.com Mon Feb 27 22:04:51 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Feb 2006 17:04:51 -0500 Subject: gphoto2 problem: usb access for non root users In-Reply-To: <20060227214503.GA5902@imperial.ac.uk> References: <561c252c0601311402s2dfa06d3s@mail.gmail.com> <200602241919.34962.jbarnes@virtuousgeek.org> <20060227171355.GA31836@devserv.devel.redhat.com> <200602270945.03846.jbarnes@virtuousgeek.org> <20060227174848.GB9529@devserv.devel.redhat.com> <20060227214503.GA5902@imperial.ac.uk> Message-ID: <20060227220451.GB6988@devserv.devel.redhat.com> Kostas Georgiou (k.georgiou at imperial.ac.uk) said: > On Mon, Feb 27, 2006 at 12:48:48PM -0500, Bill Nottingham wrote: > > > Jesse Barnes (jbarnes at virtuousgeek.org) said: > > > If I wanted to add some additional echo statements to > > > the /usr/libexec/gphoto-set-procperm where would their output show up? > > > I wanted to check and see if the environment variables were getting set > > > correctly, since everything else looks ok (guess I can just redirect to > > > a file to do some debugging, I'll try that when I get home). > > > > set > /tmp/gphoto.$$ should be simple enough for debugging. > > Well since I am home > "chown $console_user /dev/bus/usb/$bus_num/$dev_num" fails with: > chown: cannot access `/dev/bus/usb/002/018': No such file or directory > Anything that slows down the script (ls /dev/bus/usb/$bus_num, usleep 1, etc.) > seems to be enough for the device to be created. > > Should the script wait for the device to be created or is there a better > way to handle this? David: when do the hal callouts get run - shouldn't they be run after the device is created? Bill From pjones at redhat.com Mon Feb 27 22:07:48 2006 From: pjones at redhat.com (Peter Jones) Date: Mon, 27 Feb 2006 17:07:48 -0500 Subject: FC5 test3 -- dmraid broken? In-Reply-To: <001401c639ee$afd8f9b0$9a00000a@chabot> References: <001401c639ee$afd8f9b0$9a00000a@chabot> Message-ID: <1141078068.15232.15.camel@localhost.localdomain> On Sat, 2006-02-25 at 10:34 +0100, Chris Chabot wrote: > I'm very close to actually wanting to install FC5 on a brank-spanking-new > beast of a machine, but the disk configuration of it is identical to what > the initial reporter has (nvidia raid0), should I wait for a while to see a > fix for these problems in the rawhide changelog, or would it be a long wait? > :-) Tomorrow's rawhide might be worth trying ;) -- Peter From notting at redhat.com Mon Feb 27 22:11:23 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 27 Feb 2006 17:11:23 -0500 Subject: gphoto2 problem: usb access for non root users In-Reply-To: <20060227214503.GA5902@imperial.ac.uk> References: <561c252c0601311402s2dfa06d3s@mail.gmail.com> <200602241919.34962.jbarnes@virtuousgeek.org> <20060227171355.GA31836@devserv.devel.redhat.com> <200602270945.03846.jbarnes@virtuousgeek.org> <20060227174848.GB9529@devserv.devel.redhat.com> <20060227214503.GA5902@imperial.ac.uk> Message-ID: <20060227221123.GC6988@devserv.devel.redhat.com> Kostas Georgiou (k.georgiou at imperial.ac.uk) said: > On Mon, Feb 27, 2006 at 12:48:48PM -0500, Bill Nottingham wrote: > > > Jesse Barnes (jbarnes at virtuousgeek.org) said: > > > If I wanted to add some additional echo statements to > > > the /usr/libexec/gphoto-set-procperm where would their output show up? > > > I wanted to check and see if the environment variables were getting set > > > correctly, since everything else looks ok (guess I can just redirect to > > > a file to do some debugging, I'll try that when I get home). > > > > set > /tmp/gphoto.$$ should be simple enough for debugging. > > Well since I am home > "chown $console_user /dev/bus/usb/$bus_num/$dev_num" fails with: > chown: cannot access `/dev/bus/usb/002/018': No such file or directory > Anything that slows down the script (ls /dev/bus/usb/$bus_num, usleep 1, etc.) > seems to be enough for the device to be created. > > Should the script wait for the device to be created or is there a better > way to handle this? Oh, BTW. Please file a bug against hal, this appears to be due to a race between the USB device creation and the callouts. Bill From p-danlu at ssl.fujitsu.com Tue Feb 28 05:44:41 2006 From: p-danlu at ssl.fujitsu.com (LU) Date: Tue, 28 Feb 2006 14:44:41 +0900 Subject: dmraid and mkinitrd In-Reply-To: <1141018018.3592.11.camel@mentorng.gurulabs.com> References: <1141018018.3592.11.camel@mentorng.gurulabs.com> Message-ID: <20060228140957.EFD6.P-DANLU@ssl.fujitsu.com> Hi, ? I'm SORRY about it might be irrelevant to this thread, I'm working on Momonga-linux (http://www.momonga-linux.org/index.html.en) and tried to import the mkinitrd from fedora-devel. When I did make or rebuild the src of mkinitrd-5.0.28, I got such error-messages: ----------------------- from here ---------------------------------- # uname -a Linux momo.local 2.6.10-36m #1 Fri Apr 22 18:38:29 JST 2005 i686 i686 i386 GNU/Linux # LANG=C rpmbuild -bb mkinitrd.spec Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.55369 + umask 022 + cd /usr/src/momonga/BUILD + set -- + '[' 0 -gt 0 ']' + cd /usr/src/momonga/BUILD + rm -rf mkinitrd-5.0.28 + /usr/bin/bzip2 -dc /usr/src/momonga/SOURCES/mkinitrd-5.0.28.tar.bz2 + tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd mkinitrd-5.0.28 + echo 'Patch #100 (mkinitrd-5.0.28-momonga.patch):' Patch #100 (mkinitrd-5.0.28-momonga.patch): + patch -p1 -b --suffix .momonga~ -s + echo 'Patch #105 (mkinitrd-5.0.28-insmod.static.old.patch):' Patch #105 (mkinitrd-5.0.28-insmod.static.old.patch): + patch -p1 -b --suffix .insmod.static.old~ -s + exit 0 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.7114 + umask 022 + cd /usr/src/momonga/BUILD + cd mkinitrd-5.0.28 + make make -C nash all make[1]: Entering directory `/usr/src/momonga/BUILD/mkinitrd-5.0.28/nash' making /usr/src/momonga/BUILD/mkinitrd-5.0.28/nash/version.h for n in ; do make -C $n all ; done gcc -Wall -Werror -g -D_FORTIFY_SOURCE=2 -c -o lib.o lib.c gcc -Wall -Werror -g -D_FORTIFY_SOURCE=2 -c -o dm.o dm.c dm.c: In function `nashDmCreate': dm.c:189: warning: implicit declaration of function `dm_task_update_nodes' dm.c: In function `dm_submap_has_part': dm.c:678: warning: implicit declaration of function `dm_tree_create' dm.c:678: warning: assignment makes pointer from integer without a cast dm.c:684: warning: implicit declaration of function `dm_tree_add_dev' dm.c:686: warning: implicit declaration of function `dm_tree_find_node' dm.c:686: warning: assignment makes pointer from integer without a cast dm.c:688: warning: implicit declaration of function `dm_tree_next_child' dm.c:688: warning: assignment makes pointer from integer without a cast dm.c:694: warning: implicit declaration of function `dm_tree_node_get_name' dm.c:695: warning: passing arg 2 of `nashDmTaskNew' makes pointer from integer without a cast dm.c:716: warning: assignment makes pointer from integer without a cast dm.c:742: warning: implicit declaration of function `dm_tree_free' make[1]: *** [dm.o] Error 1 make[1]: Leaving directory `/usr/src/momonga/BUILD/mkinitrd-5.0.28/nash' make: *** [nash] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.7114 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.7114 (%build) ----------------------- above ---------------------------------- Could anyone pls give me some advice into find the solution about this? *I got the same error when only "make" from the src tree. ### PS. The patch files for momonga-linux: ------------------------------------------------------------------------------------- # cat mkinitrd-5.0.28-momonga.patch --- mkinitrd-5.0.28/grubby/new-kernel-pkg.def 2006-02-28 13:17:52.751654680 +0900 +++ mkinitrd-5.0.28/grubby/new-kernel-pkg 2006-02-28 13:20:26.978208680 +0900 @@ -7,6 +7,7 @@ # addition/removal of kernel images from grub/lilo configuration (via grubby) # # Copyright (C) 2002-2005 Red Hat, Inc. +# Copyright (C) 2006 Momonga Project. # PATH=/sbin:/bin:$PATH @@ -139,7 +140,7 @@ elif [ -f /etc/redhat-release ]; then title="$(sed 's/ release.*$//' < /etc/redhat-release) ($version)" else - title="Red Hat Linux ($version)" + title="Momonga Linux ($version)" fi /sbin/grubby --add-kernel=$bootPrefix/$kernelName-$version \ $INITRD --copy-default $makedefault --title "$title" \ ------------------------------------------------------------------------------------- # cat mkinitrd-5.0.28-insmod.static.old.patch --- mkinitrd-5.0.28/mkinitrd.def 2006-02-28 13:24:34.523576064 +0900 +++ mkinitrd-5.0.28/mkinitrd 2006-02-28 13:24:39.938752832 +0900 @@ -797,7 +797,15 @@ inst /etc/fstab.sys "$MNTIMAGE/etc/fstab.sys" fi inst /sbin/nash "$MNTIMAGE/bin/nash" -inst /sbin/insmod.static "$MNTIMAGE/bin/insmod" +if [ `echo "$kernel"|cut -d'.' -f1-2` = "2.4" ]; then + if [ -f /sbin/insmod.static.old ]; then + inst /sbin/insmod.static.old "$MNTIMAGE/bin/insmod" + else + inst /sbin/insmod.static "$MNTIMAGE/bin/insmod" + fi +else + inst /sbin/insmod.static "$MNTIMAGE/bin/insmod" +fi ln -s /sbin/nash $MNTIMAGE/sbin/modprobe for MODULE in $MODULES; do ------------------------------------------------------------------------------------- On Sun, 26 Feb 2006 22:26:58 -0700 Dax Kelson wrote: ?> In stock Fedora Core 5 test 3 with a mkinitrd-5.0.26 created initramfs ?> the dmraid was not properly activated. ?> ?> I did a fresh install of FC5 test and upgraded to mkinitrd-5.0.28 inside ?> the rescue environment. I rebuilt the initial ram disk and I'm happy to ?> report that it fixes the problem. ?> ?> More details are available in the bug I filed. ?> ?> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182446 ?> ?> Dax Kelson ?> Guru Labs ?> ?> -- ?> fedora-devel-list mailing list ?> fedora-devel-list at redhat.com ?> https://www.redhat.com/mailman/listinfo/fedora-devel-list From gianluca.cecchi at gmail.com Tue Feb 28 07:05:21 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Tue, 28 Feb 2006 08:05:21 +0100 Subject: gphoto2 problem: usb access for non root users In-Reply-To: <200602270945.03846.jbarnes@virtuousgeek.org> References: <561c252c0601311402s2dfa06d3s@mail.gmail.com> <200602241919.34962.jbarnes@virtuousgeek.org> <20060227171355.GA31836@devserv.devel.redhat.com> <200602270945.03846.jbarnes@virtuousgeek.org> Message-ID: <561c252c0602272305j3ce08b12o@mail.gmail.com> I was out last week (holiday, eh eh ;-) and now I'm downloading test3 torrents. My system is up2date at 18th of February at the moment and I work without any problem. I'll let you know after test3. >From your e-mail, I presume you are in kde as DE, aren't you? Could it be that interferring in some way? I only made my tests with gnome running and using gphoto2 comand to debug and digikam as fe application. Today when @home I can test with kde too, to see pop ups. In gnome I have no automatic graphic pop ups, I have to run digikam after inserting digicamera. I have to open a bug because for example if you mount a filesystem when inside gnome, when you exit, it is automatically dismounted.... so in initialitation phases it seems there some triggers that could interfere also in your case, just an attempt... Apart from the kde popups, the messages that you receive with gphoto2 --auto-detect are the same as mine at the beginning of the thread, with success for root and nothing for users? Other messages in /var/log/messages or with dmesg command? And what about exact permissions assigned to files/directories I cited in my posts? Gianluca 2006/2/27, Jesse Barnes : > On Monday, February 27, 2006 9:13 am, Bill Nottingham wrote: > > Jesse Barnes (jbarnes at virtuousgeek.org) said: > > > Hm, I haven't been so lucky. When I plugin my camera, I get a popup > > > under KDE asking me if I want to open a window. If I select 'yes' > > > the window comes up but times out saying it couldn't claim the usb > > > device, presumably because both /proc/bus/usb and /dev/bus/usb are > > > owned completely by root. From buildsys at redhat.com Tue Feb 28 08:19:06 2006 From: buildsys at redhat.com (Build System) Date: Tue, 28 Feb 2006 03:19:06 -0500 Subject: rawhide report: 20060228 changes Message-ID: <200602280819.k1S8J6eT009069@porkchop.devel.redhat.com> Removed package libibverbs Removed package opensm Removed package libsdp Removed package udapl Removed package libmthca Updated Packages: GConf-1.0.9-20 -------------- * Mon Feb 27 2006 Karsten Hopp 1.0.9-20 - BuildRequires zlib-devel * Fri Feb 24 2006 Matthias Clasen - 1.0.9-19 - Prereq: coreutils * Mon Feb 13 2006 Jesse Keating - 1.0.9-18.2.1 - rebump for build order issues during double-long bump NetworkManager-0.5.1-15.cvs20060227 ----------------------------------- * Mon Feb 27 2006 Christopher Aillon 0.5.1-15.cvs20060227 - Update snapshot, which fixes up the libnotify stuff. anaconda-10.92.12-1 ------------------- * Mon Feb 27 2006 Jeremy Katz - 10.92.12-1 - Dependency whiteout to fix ordering (clumens) - Fix swap on RAID in kickstart (#176537) - Add keymap overrides - Fix segfault with USB CD/DVD drives (#182589) at-spi-1.7.6-1 -------------- * Mon Feb 27 2006 Matthias Clasen - 1.7.6-1 - Update to 1.7.6 authconfig-5.2.2-1 ------------------ * Mon Feb 27 2006 Tomas Mraz - 5.2.2-1 - add try_first_pass option to pam_unix for better integration with individual service configurations (#182350) - updated translations boost-1.33.1-5 -------------- * Thu Feb 16 2006 Florian La Roche - 1.33.1-5 - use the real version number to point to the shared libs booty-0.68-1 ------------ * Mon Feb 27 2006 Peter Jones - 0.68-1 - sync between invocations of grub on smp - default to "mbr", not "partition" for grub installation on md bug-buddy-1:2.13.90-1 --------------------- * Mon Feb 27 2006 Matthias Clasen - 2.13.90-1 - Update to 2.13.90 * Fri Feb 17 2006 Karsten Hopp 2.13.0-2 - BuildRequires: which cryptsetup-luks-1.0.3-0.rc2 --------------------------- * Mon Feb 27 2006 Bill Nottingham 1.0.3-0.rc2 - update to 1.0.3rc2, fixes bug with HAL & encrypted devices (#182658) eel2-2.13.92-1 -------------- * Mon Feb 27 2006 Matthias Clasen - 2.13.92-1 - Update to 2.13.92 epiphany-1.9.8-1 ---------------- * Mon Feb 27 2006 Matthias Clasen - 1.9.8-1 - Update to 1.9.8 evince-0.5.1-1 -------------- * Mon Feb 27 2006 Matthias Clasen - 0.5.1-1 - Update to 0.5.1 - Drop upstreamed patch file-roller-2.13.92-1 --------------------- * Mon Feb 27 2006 Matthias Clasen - 2.13.92-1 - Update to 2.13.92 g-wrap-1.9.6-2 -------------- * Mon Feb 27 2006 Bill Nottingham 1.9.6-2 - don't use an executable stack (#183287) gal-1:0.24-7 ------------ * Mon Feb 27 2006 Karsten Hopp 0.24-7 - BuildRequires: libSM-devel gcc-4.1.0-0.30 -------------- * Mon Feb 27 2006 Jakub Jelinek 4.1.0-0.30 - update from gcc-4_1-branch (-r111278:111466) - GCC 4.1.0 RC2 - PRs fortran/26201, libobjc/26309, rtl-optimization/25603, target/25603 - fix nested vector shifts (#182047, PR middle-end/26379) - merge gomp changes from trunk (-r111390:111391, -r111428:111429 and -r111440:111441) - PR middle-end/26412 - fortran MATMUL optimization (Richard Sandiford) - fortran WHERE optimizations (Roger Sayle) - x86_64 _mm_monitor fixes (H.J. Lu, PR target/24879) - add MNI support on i?86/x86_64, -mmni option and header (H.J Lu) gnome-bluetooth-0.7.0-2 ----------------------- * Mon Feb 27 2006 Harald Hoyer - 0.7.0-2 - pydir fixes for lib64 * Thu Feb 16 2006 Harald Hoyer - 0.7.0-1 - version 0.7.0 gnome-desktop-2.13.92-1 ----------------------- * Mon Feb 27 2006 Matthias Clasen - 2.13.92-1 - Update to 2.13.92 gnome-doc-utils-0.5.7-1 ----------------------- * Mon Feb 27 2006 Matthias Clasen - 0.5.7-1 - Update to 0.5.7 gnome-keyring-0.4.8-1 --------------------- * Mon Feb 27 2006 Matthias Clasen - 0.4.8-1 - Update to 0.4.8 gnome-media-2.13.93-1 --------------------- * Mon Feb 27 2006 Matthias Clasen - 2.13.93-1 - Update to 2.13.93 gnome-panel-2.13.91-4 --------------------- * Mon Feb 27 2006 Ray Strode - 2.13.91-4 - ignore unknown options (bug 182734) gnome-screensaver-2.13.92-1 --------------------------- * Mon Feb 27 2006 Matthias Clasen - 2.13.92-1 - Update to 2.13.92 gnome-system-monitor-2.13.92-1 ------------------------------ * Mon Feb 27 2006 Matthias Clasen 2.13.92-1 - Update to 2.13.92 gnome-vfs2-2.13.92-1 -------------------- * Mon Feb 27 2006 Matthias Clasen - 2.13.92-1 - Update to 2.13.92 irqbalance-1:1.12-1.25 ---------------------- * Sun Feb 26 2006 Dave Jones - Don't rebalance IRQs where no interrupts have occured. kernel-2.6.15-1.1991_FC5 ------------------------ * Mon Feb 27 2006 Dave Jones - 2.6.16rc5 & rc5-git1 * Sun Feb 26 2006 Dave Jones - 2.6.16rc4-git9 & -git10 - Temporarily disable xen due to build breakage. * Sat Feb 25 2006 Dave Jones - 2.6.16rc4-git8 libgnome-2.13.90-1 ------------------ * Mon Feb 27 2006 Matthias Clasen - 2.13.90-1 - Update to 2.13.90 - Drop obsolete patch libgnomeui-2.13.90-1 -------------------- * Mon Feb 27 2006 Matthias Clasen - 2.13.90-1 - Update to 2.13.90 libgtop2-2.13.92-1 ------------------ * Mon Feb 27 2006 Matthias Clasen - 2.13.92-1 - Update to 2.13.92 libtermcap-2.0.8-45 ------------------- * Mon Feb 27 2006 Miloslav Trmac - 2.0.8-45 - Add Requires(postun): /sbin/install-info to libtermcap-devel (#182836) libvirt-0.0.5-1 --------------- * Thu Feb 23 2006 Daniel Veillard 0.0.5-1 - new domain creation API - new UUID based APIs - more tests, documentation, devhelp - bug fixes libwnck-2.13.92-1 ----------------- * Mon Feb 27 2006 Matthias Clasen - 2.13.92-1 - Update to 2.13.92 mkinitrd-5.0.29-1 ----------------- * Mon Feb 27 2006 Peter Jones - 5.0.29-1 - Fix pump-devel buildrequires - Fix grubby's getpathbyspec() usage (#183010) - Fix grubby's makefile - Make readlink command work with super scary huge sysfs paths (#183091) - Make readlink handle directories better (#166666) - Don't create ramdisk blockdevs, mkblkdevs does it (#181873) - Don't use showlabels to resolve labels, use resolveDevice so we don't need messy awk (#180372) mod_python-3.2.8-3 ------------------ * Mon Feb 27 2006 Joe Orton 3.2.8-3 - remove use of apr_sockaddr_port_get * Mon Feb 27 2006 Joe Orton 3.2.8-2 - update to 3.2.8 nautilus-2.13.92-1 ------------------ * Mon Feb 27 2006 Matthias Clasen - 2.13.92-1 - Update to 2.13.92 * Mon Feb 13 2006 Matthias Clasen - 2.13.91-1 - Update to 2.13.91 * Fri Feb 10 2006 Jesse Keating - 2.13.90-2.2 - bump again for double-long bug on ppc(64) nautilus-cd-burner-2.13.92-1 ---------------------------- * Mon Feb 27 2006 Matthias Clasen - 2.13.92-1 - Update to 2.13.92 - Drop upstreamed patch - Add BuildReq for gnome-mount openobex-1.1-1 -------------- * Thu Feb 16 2006 Harald Hoyer 1.1-1 - version 1.1 * Fri Feb 10 2006 Jesse Keating - 1.0.1-4.2.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 1.0.1-4.2 - rebuilt for new gcc4.1 snapshot and glibc changes openobex-apps-1.0.0-10 ---------------------- * Fri Feb 24 2006 Harald Hoyer - 1.0.0-10 - rebuilt for openobex-1.1 * Thu Feb 16 2006 Harald Hoyer - 1.0.0-9 - rebuilt for openobex-1.1 pam-0.99.3.0-2 -------------- * Fri Feb 24 2006 Tomas Mraz 0.99.3.0-2 - added try_first_pass option to pam_cracklib - use try_first_pass for pam_unix and pam_cracklib in system-auth (#182350) * Fri Feb 10 2006 Jesse Keating - 0.99.3.0-1.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 0.99.3.0-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes pirut-0.9.16-1 -------------- * Mon Feb 27 2006 Jeremy Katz - 0.9.16-1 - Fix optional package searching (#182555) - Catch errors when downloading metadata (#178641) - Some UI changes from Simon Lanzmich (#182644) - More UI changes from jrb psacct-6.3.2-41 --------------- * Mon Feb 27 2006 Peter Jones - 6.3.2-41 - add touch to prereq * Mon Feb 27 2006 Ivana Varekova - 6.3.2-40 - add chkconfig to prereq - bug 182848 struts-0:1.2.8-2jpp_9fc ----------------------- * Fri Feb 24 2006 Rafael Schloming - 0:1.2.8-2jpp_9fc - Removed the webapps-tomcat{3,4} subpackages. system-switch-mail-0.5.25-7 --------------------------- * Mon Feb 27 2006 Than Ngo 0.5.25-7 - fix consolehelper config #160931 tomcat5-0:5.5.15-1jpp_3fc ------------------------- * Thu Feb 23 2006 Rafael Schloming - 0:5.5.15-1jpp_3fc - Added jasper-foo symlinks for jars. * Wed Feb 22 2006 Rafael Schloming - 0:5.5.15-1jpp_2fc - Exclude ppc64 s390 s390x * Wed Feb 22 2006 Rafael Schloming - 0:5.5.15-1jpp_1fc - Updated to 5.5.15 util-linux-2.13-0.16 -------------------- * Wed Feb 22 2006 Karel Zak 2.13-0.16 - fix #181782 - mkswap should automatically add selinux label to swapfile - fix #180730 - col is exiting with 1 (fix util-linux-2.12p-col-EILSEQ.patch) - fix #181896 - broken example in schedutils man pages - fix #177331 - login omits pam_acct_mgmt & pam_chauthtok when authentication is skipped. - fix #177523 - umount -a should not unmount sysfs - fix #182553 - fdisk -l inside xen guest shows no disks wpa_supplicant-1:0.4.8-1 ------------------------ * Fri Feb 24 2006 Dan Williams - 0.4.8-1 - Downgrade to 0.4.8 stable release rather than a dev release xorg-x11-fonts-7.0-2 -------------------- * Fri Feb 24 2006 Mike A. Harris 7.0-2 - Generate encodings.dir files in the encodings dirs with mkfontscale from the base fonts package post install script, to work around bug (#173875) Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15-5.FC5.4.i686 requires kernel = 0:2.6.15-1.1955_FC5 GFS-kernel - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5 GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 GFS-kernel-smp - 2.6.15-5.FC5.4.i686 requires /lib/modules/2.6.15-1.1955_FC5smp cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 cman-kernel-smp - 2.6.15.0-20051219.162641.FC5.11.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 dlm-kernel-smp - 2.6.15.0-20051219.162641.FC5.9.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp gnbd-kernel - 2.6.15-5.FC5.7.i686 requires kernel = 0:2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires kernel-smp = 0:2.6.15-1.1955_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.7.i686 requires /lib/modules/2.6.15-1.1955_FC5smp Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs vconfig - 1.9-1.1.ia64 requires libc.so.6 vconfig - 1.9-1.1.ia64 requires libc.so.6(GLIBC_2.0) Broken deps for ppc64 ---------------------------------------------------------- emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi vconfig - 1.9-1.1.ppc64 requires libc.so.6 vconfig - 1.9-1.1.ppc64 requires libc.so.6(GLIBC_2.0) Broken deps for s390 ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 Broken deps for s390x ---------------------------------------------------------- rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 GFS-kernel - 2.6.15-5.FC5.4.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 cman-kernel - 2.6.15.0-20051219.162641.FC5.11.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 dlm-kernel - 2.6.15.0-20051219.162641.FC5.9.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires kernel = 0:2.6.15-1.1955_FC5 gnbd-kernel - 2.6.15-5.FC5.7.x86_64 requires /lib/modules/2.6.15-1.1955_FC5 From gazzerh at gmail.com Tue Feb 28 14:30:35 2006 From: gazzerh at gmail.com (Garry Harthill) Date: Tue, 28 Feb 2006 14:30:35 +0000 Subject: Java - Azureus memory usage Message-ID: <1fcc9e320602280630j5c2aa5c6h@mail.gmail.com> top - 14:24:28 up 5 days, 3:41, 5 users, load average: 3.78, 3.61, 3.27 Tasks: 117 total, 1 running, 116 sleeping, 0 stopped, 0 zombie Cpu(s): 57.0% us, 10.3% sy, 0.0% ni, 31.1% id, 1.3% wa, 0.3% hi, 0.0% si Mem: 1027288k total, 1002144k used, 25144k free, 39564k buffers Swap: 1020116k total, 940k used, 1019176k free, 405756k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13132 garry 15 0 966m 213m 37m S 50.6 21.3 227:27.00 gij 213mb memory and 50% CPU seems a bit excessive. azureus-2.4.0.0-0.20060209cvs_1.fc5 glib-java-0.2.3-1.2 cairo-java-1.0.2-0.2 libgconf-java-2.12.1-2.2 libgtk-java-2.8.3-1.2 java-1.4.2-gcj-compat-1.4.2.0-40jpp_80rh Anyone else seeing this? Garry From aph at redhat.com Tue Feb 28 14:41:57 2006 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 Feb 2006 14:41:57 +0000 Subject: Java - Azureus memory usage In-Reply-To: <1fcc9e320602280630j5c2aa5c6h@mail.gmail.com> References: <1fcc9e320602280630j5c2aa5c6h@mail.gmail.com> Message-ID: <17412.24885.59516.767056@zapata.pink> Garry Harthill writes: > top - 14:24:28 up 5 days, 3:41, 5 users, load average: 3.78, 3.61, 3.27 > Tasks: 117 total, 1 running, 116 sleeping, 0 stopped, 0 zombie > Cpu(s): 57.0% us, 10.3% sy, 0.0% ni, 31.1% id, 1.3% wa, 0.3% hi, 0.0% si > Mem: 1027288k total, 1002144k used, 25144k free, 39564k buffers > Swap: 1020116k total, 940k used, 1019176k free, 405756k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 13132 garry 15 0 966m 213m 37m S 50.6 21.3 227:27.00 gij > > 213mb memory and 50% CPU seems a bit excessive. > > azureus-2.4.0.0-0.20060209cvs_1.fc5 > glib-java-0.2.3-1.2 > cairo-java-1.0.2-0.2 > libgconf-java-2.12.1-2.2 > libgtk-java-2.8.3-1.2 > java-1.4.2-gcj-compat-1.4.2.0-40jpp_80rh > > Anyone else seeing this? When you start azureus, use 'gij -verbose:class'. See if any of the classes are loaded 'bytecode'. Andrew. From fedora at camperquake.de Tue Feb 28 15:22:28 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 28 Feb 2006 16:22:28 +0100 Subject: Java - Azureus memory usage In-Reply-To: <17412.24885.59516.767056@zapata.pink> References: <1fcc9e320602280630j5c2aa5c6h@mail.gmail.com> <17412.24885.59516.767056@zapata.pink> Message-ID: <20060228162228.0f1eb3ec@dhcp05.addix.net> Hi On Tue, 28 Feb 2006 14:41:57 +0000, Andrew Haley wrote: > > Anyone else seeing this? > > When you start azureus, use 'gij -verbose:class'. See if any of the > classes are loaded 'bytecode'. 2929 unique classes. I'm impressed. Some of these are bytecode, indeed. Complete list is attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: azureus-bytecode.txt.gz Type: application/x-gzip Size: 1416 bytes Desc: not available URL: From pnasrat at redhat.com Tue Feb 28 16:14:34 2006 From: pnasrat at redhat.com (Paul Nasrat) Date: Tue, 28 Feb 2006 11:14:34 -0500 Subject: python and rpm In-Reply-To: <43FEB000.3020403@rasmil.dk> References: <13dbfe4f0602230749o277329ffu1754b4eaa7826c1e@mail.gmail.com> <43FEB000.3020403@rasmil.dk> Message-ID: <1141143274.2461.70.camel@enki.eridu> On Fri, 2006-02-24 at 08:04 +0100, Tim Lauridsen wrote: > Chitlesh GOORAH wrote: > > What about something like this > > for mi in ts.dbMatch ('name', 'kernel'): > name = mi['name'] > if name.find('hypervisor') <> -1: > # Do the stuff Or you could use mi.pattern mi = ts.dbMatch() mi.pattern("name",rpm.RPMMIRE_GLOB,"kernel*hypervisor") Paul From brilong at cisco.com Tue Feb 28 16:56:57 2006 From: brilong at cisco.com (Brian Long) Date: Tue, 28 Feb 2006 11:56:57 -0500 Subject: rawhide report: 20060228 changes In-Reply-To: <200602280819.k1S8J6eT009069@porkchop.devel.redhat.com> References: <200602280819.k1S8J6eT009069@porkchop.devel.redhat.com> Message-ID: <1141145817.4433.34.camel@brilong-lnx> On Tue, 2006-02-28 at 03:19 -0500, Build System wrote: > > Removed package libibverbs > > Removed package opensm > > Removed package libsdp > > Removed package udapl > > Removed package libmthca OpenIB is removed from RawHide? /Brian/ -- Brian Long | | | IT Data Center Systems | .|||. .|||. Cisco Linux Developer | ..:|||||||:...:|||||||:.. Phone: (919) 392-7363 | C i s c o S y s t e m s From notting at redhat.com Tue Feb 28 17:00:30 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 28 Feb 2006 12:00:30 -0500 Subject: rawhide report: 20060228 changes In-Reply-To: <1141145817.4433.34.camel@brilong-lnx> References: <200602280819.k1S8J6eT009069@porkchop.devel.redhat.com> <1141145817.4433.34.camel@brilong-lnx> Message-ID: <20060228170030.GI2021@devserv.devel.redhat.com> Brian Long (brilong at cisco.com) said: > > Removed package libibverbs > > > > Removed package opensm > > > > Removed package libsdp > > > > Removed package udapl > > > > Removed package libmthca > > OpenIB is removed from RawHide? At the request of the OpenIB maintainers, yes. They're intending to import it into Extras in the very near future. Bill From orion at cora.nwra.com Tue Feb 28 17:03:16 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 28 Feb 2006 10:03:16 -0700 Subject: rawhide report: 20060227 changes - gtk2 circular dep In-Reply-To: <200602270817.k1R8HK4Q008251@porkchop.devel.redhat.com> References: <200602270817.k1R8HK4Q008251@porkchop.devel.redhat.com> Message-ID: > gtk2-2.8.13-1 > ------------- > * Sat Feb 25 2006 Matthias Clasen - 2.8.13-1 > - Update to 2.8.13 > > * Fri Feb 24 2006 Ray Strode - 2.8.12-8 > - add dependency on hicolor > This has created a circular dependency with hicolor #rpm -qp --requires gtk2-2.8.13-1.i386.rpm /bin/sh /bin/sh /bin/sh atk >= 1.6.0-1 glib2 >= 2.7.1-1 hicolor-icon-theme # rpm -qp --requires hicolor-icon-theme-0.9-1.noarch.rpm /bin/sh /bin/sh coreutils coreutils gtk2 >= 2.6.0 and is breaking Fedora Extras builds https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183361 From chitlesh at fedoraproject.org Tue Feb 28 17:06:54 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 28 Feb 2006 18:06:54 +0100 Subject: python and rpm In-Reply-To: <1141143274.2461.70.camel@enki.eridu> References: <13dbfe4f0602230749o277329ffu1754b4eaa7826c1e@mail.gmail.com> <43FEB000.3020403@rasmil.dk> <1141143274.2461.70.camel@enki.eridu> Message-ID: <13dbfe4f0602280906o70658b7s5baebe61cdfa258d@mail.gmail.com> On 2/28/06, Paul Nasrat wrote: > On Fri, 2006-02-24 at 08:04 +0100, Tim Lauridsen wrote: > > Chitlesh GOORAH wrote: > > > > What about something like this > > > > for mi in ts.dbMatch ('name', 'kernel'): > > name = mi['name'] > > if name.find('hypervisor') <> -1: > > # Do the stuff > > Or you could use mi.pattern > mi = ts.dbMatch() > mi.pattern("name",rpm.RPMMIRE_GLOB,"kernel*hypervisor") > > Paul Ill try yours in a few, Ive came up to this for the moment which might not be the perfect algo: def xen_is_installed(rootdir): clear_rpm_db_files (rootdir) ts = rpm.TransactionSet(rootdir) for mi in ts.dbMatch (): name = mi['name'] if name.find('hypervisor') <> -1: # for /lib/modules kernel_version = "%s-%s%s" % (mi['version'], mi['release'], 'hypervisor') clear_rpm_db_files (rootdir) return kernel_version Chitlesh GOORAH -- http://clunixchit.blogspot.com From brilong at cisco.com Tue Feb 28 17:08:48 2006 From: brilong at cisco.com (Brian Long) Date: Tue, 28 Feb 2006 12:08:48 -0500 Subject: rawhide report: 20060228 changes In-Reply-To: <20060228170030.GI2021@devserv.devel.redhat.com> References: <200602280819.k1S8J6eT009069@porkchop.devel.redhat.com> <1141145817.4433.34.camel@brilong-lnx> <20060228170030.GI2021@devserv.devel.redhat.com> Message-ID: <1141146528.4433.38.camel@brilong-lnx> On Tue, 2006-02-28 at 12:00 -0500, Bill Nottingham wrote: > Brian Long (brilong at cisco.com) said: > > > Removed package libibverbs > > > > > > Removed package opensm > > > > > > Removed package libsdp > > > > > > Removed package udapl > > > > > > Removed package libmthca > > > > OpenIB is removed from RawHide? > > At the request of the OpenIB maintainers, yes. They're intending to > import it into Extras in the very near future. Interesting. If it's not in Core, but Extras (and it's a Tech Preview in RHEL 4 U3), how would it make it into RHEL 5? :-) Is the thought it might move back to Core in Fedora Core 6 and then inherently make it into RHEL 5? /Brian/ -- Brian Long | | | IT Data Center Systems | .|||. .|||. Cisco Linux Developer | ..:|||||||:...:|||||||:.. Phone: (919) 392-7363 | C i s c o S y s t e m s From notting at redhat.com Tue Feb 28 17:12:08 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 28 Feb 2006 12:12:08 -0500 Subject: rawhide report: 20060228 changes In-Reply-To: <1141146528.4433.38.camel@brilong-lnx> References: <200602280819.k1S8J6eT009069@porkchop.devel.redhat.com> <1141145817.4433.34.camel@brilong-lnx> <20060228170030.GI2021@devserv.devel.redhat.com> <1141146528.4433.38.camel@brilong-lnx> Message-ID: <20060228171208.GK2021@devserv.devel.redhat.com> Brian Long (brilong at cisco.com) said: > Interesting. If it's not in Core, but Extras (and it's a Tech Preview > in RHEL 4 U3), how would it make it into RHEL 5? :-) Is the thought it > might move back to Core in Fedora Core 6 and then inherently make it > into RHEL 5? Core is not a prerequsite for RHEL. Bill From mailinglists at erwinrol.com Tue Feb 28 17:12:19 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Tue, 28 Feb 2006 18:12:19 +0100 Subject: rawhide report: 20060227 changes - gtk2 circular dep In-Reply-To: References: <200602270817.k1R8HK4Q008251@porkchop.devel.redhat.com> Message-ID: <1141146739.7702.41.camel@xpc.home.erwinrol.com> On Tue, 2006-02-28 at 10:03 -0700, Orion Poplawski wrote: > # rpm -qp --requires hicolor-icon-theme-0.9-1.noarch.rpm > /bin/sh > /bin/sh > coreutils > coreutils > gtk2 >= 2.6.0 Why do icons require a toolkit like GTK ? - Erwin From orion at cora.nwra.com Tue Feb 28 17:19:50 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 28 Feb 2006 10:19:50 -0700 Subject: rawhide report: 20060227 changes - gtk2 circular dep In-Reply-To: <1141146739.7702.41.camel@xpc.home.erwinrol.com> References: <200602270817.k1R8HK4Q008251@porkchop.devel.redhat.com> <1141146739.7702.41.camel@xpc.home.erwinrol.com> Message-ID: <44048636.9080502@cora.nwra.com> Erwin Rol wrote: > > Why do icons require a toolkit like GTK ? > > - Erwin > > Perhaps: # rpm -qp --scripts hicolor-icon-theme-0.9-1.noarch.rpm postinstall scriptlet (using /bin/sh): touch --no-create /usr/share/icons/hicolor if [ -x /usr/bin/gtk-update-icon-cache ]; then gtk-update-icon-cache --quiet /usr/share/icons/hicolor fi exit 0 postuninstall scriptlet (using /bin/sh): touch --no-create /usr/share/icons/hicolor if [ -x /usr/bin/gtk-update-icon-cache ]; then gtk-update-icon-cache --quiet /usr/share/icons/hicolor fi exit 0 So it really should be: Requires(post): /usr/bin/gtk-update-icon-cache but not sure if this helps the circular dep. And it's not even a hard requires there as at least the script works without gtk-update-icon-cache. Perhaps a trigger (he says not knowing anything about triggers)? From orion at cora.nwra.com Tue Feb 28 17:19:50 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 28 Feb 2006 10:19:50 -0700 Subject: rawhide report: 20060227 changes - gtk2 circular dep In-Reply-To: <1141146739.7702.41.camel@xpc.home.erwinrol.com> References: <200602270817.k1R8HK4Q008251@porkchop.devel.redhat.com> <1141146739.7702.41.camel@xpc.home.erwinrol.com> Message-ID: <44048636.9080502@cora.nwra.com> Erwin Rol wrote: > > Why do icons require a toolkit like GTK ? > > - Erwin > > Perhaps: # rpm -qp --scripts hicolor-icon-theme-0.9-1.noarch.rpm postinstall scriptlet (using /bin/sh): touch --no-create /usr/share/icons/hicolor if [ -x /usr/bin/gtk-update-icon-cache ]; then gtk-update-icon-cache --quiet /usr/share/icons/hicolor fi exit 0 postuninstall scriptlet (using /bin/sh): touch --no-create /usr/share/icons/hicolor if [ -x /usr/bin/gtk-update-icon-cache ]; then gtk-update-icon-cache --quiet /usr/share/icons/hicolor fi exit 0 So it really should be: Requires(post): /usr/bin/gtk-update-icon-cache but not sure if this helps the circular dep. And it's not even a hard requires there as at least the script works without gtk-update-icon-cache. Perhaps a trigger (he says not knowing anything about triggers)? From rdieter at math.unl.edu Tue Feb 28 17:37:44 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 28 Feb 2006 11:37:44 -0600 Subject: rawhide report: 20060227 changes - gtk2 circular dep In-Reply-To: <44048636.9080502@cora.nwra.com> References: <200602270817.k1R8HK4Q008251@porkchop.devel.redhat.com> <1141146739.7702.41.camel@xpc.home.erwinrol.com> <44048636.9080502@cora.nwra.com> Message-ID: <44048A68.40209@math.unl.edu> Orion Poplawski wrote: > Erwin Rol wrote: >> Why do icons require a toolkit like GTK ? It doesn't. > Perhaps: > > # rpm -qp --scripts hicolor-icon-theme-0.9-1.noarch.rpm > postinstall scriptlet (using /bin/sh): > touch --no-create /usr/share/icons/hicolor > if [ -x /usr/bin/gtk-update-icon-cache ]; then > gtk-update-icon-cache --quiet /usr/share/icons/hicolor > fi > exit 0 > So it really should be: > Requires(post): /usr/bin/gtk-update-icon-cache Or do what http://fedoraproject.org/wiki/ScriptletSnippets suggests: "Note that no dependencies should be added for this" -- Rex From dominik at greysector.net Tue Feb 28 17:43:14 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 28 Feb 2006 18:43:14 +0100 Subject: Java - Azureus memory usage In-Reply-To: <1fcc9e320602280630j5c2aa5c6h@mail.gmail.com> References: <1fcc9e320602280630j5c2aa5c6h@mail.gmail.com> Message-ID: <20060228174314.GC3383@rathann.pekin.waw.pl> On Tuesday, 28 February 2006 at 15:30, Garry Harthill wrote: > top - 14:24:28 up 5 days, 3:41, 5 users, load average: 3.78, 3.61, 3.27 > Tasks: 117 total, 1 running, 116 sleeping, 0 stopped, 0 zombie > Cpu(s): 57.0% us, 10.3% sy, 0.0% ni, 31.1% id, 1.3% wa, 0.3% hi, 0.0% si > Mem: 1027288k total, 1002144k used, 25144k free, 39564k buffers > Swap: 1020116k total, 940k used, 1019176k free, 405756k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 13132 garry 15 0 966m 213m 37m S 50.6 21.3 227:27.00 gij > > 213mb memory and 50% CPU seems a bit excessive. > > azureus-2.4.0.0-0.20060209cvs_1.fc5 > glib-java-0.2.3-1.2 > cairo-java-1.0.2-0.2 > libgconf-java-2.12.1-2.2 > libgtk-java-2.8.3-1.2 > java-1.4.2-gcj-compat-1.4.2.0-40jpp_80rh > > Anyone else seeing this? What I'm seeing is deficient functionality. FE version seems to be able to handle only one download at a time and at far lower speed, i.e. only one of all active downloads actually shows any "Down speed", all others are at zero. It is also much slower in connecting to tracker and finding out how many peers and seeds there are. The binary from azureus.sf.net coupled with jpackage.org's sun java rpm works flawlessly and handles as many concurrent downloads as I want. Regards, R. -- RPM repository for Fedora Core http://rpm.greysector.net/ mpg321, xmp, faad2, lame, mad, *mplayer*, rdesktop, tin, xvid, mks, mutt "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jdesbonnet at gmail.com Tue Feb 28 18:18:36 2006 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Tue, 28 Feb 2006 18:18:36 +0000 Subject: Announcement: update RPMs using delta compression for low bandwidth users Message-ID: <1cef3e950602281018l69a9eecdre17e4460a217361d@mail.gmail.com> This software is for individual Fedora users and sys-admins who need to update one or more Fedora systems that are connected to the internet with low to medium bandwidth link (eg dialup, ISDN, satellite). The problem: Not long after a new Fedora Core release, the bandwidth required to update a fresh installation can become burdensome for low/medium bandwidth internet connections. Some update RPMs can be over 80 MBytes in size, yet the update may be almost identical to the original RPM on the distribution disk. This software presents two solutions to administrators of Fedora systems: 1. A HTTP service which acts as a virtual update RPM repository. It dynamically re-creates update RPMs by downloading a small 'patch' or 'delta' file and applying it to locally stored RPMs from the original distribution. 2. A command line tool which can regenerate an update RPM repository from a delta repository + RPMs from the original distribution. In addition to the virtual update repository, this software distribution also contains the tools needed to create and maintain a delta repository. I have also made an experimental delta repository which is open to testers (subject to sufficient bandwidth). Requirements and limitations: * This system uses Michael Schroeder's deltarpm system and must be installed (documented in the installation instructions) * Java (tested with the Fedora free stack and Sun Java) * For the HTTP service you need tomcat5 (the version in the Fedora distribution will work) * For delta repository generation you need lots of RAM to process some of the larger RPMs (eg OpenOffice core). 512MB just about works with some page faulting, 1024MB+ recommended. Software version: 0.2.0 (28 Feb 2006) Binary download: http://www.wombat.ie/software/rpmdc/downloads/RPMDC-0.2.0-bin.tar.gz Source download: http://www.wombat.ie/software/rpmdc/downloads/RPMDC-0.2.0-src.tar.gz Manual: http://www.wombat.ie/software/rpmdc/manual.html Release notes: http://www.wombat.ie/software/rpmdc/releasenotes-0.2.0.html From aph at redhat.com Tue Feb 28 18:37:47 2006 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 Feb 2006 18:37:47 +0000 Subject: Java - Azureus memory usage In-Reply-To: <17412.24885.59516.767056@zapata.pink> References: <1fcc9e320602280630j5c2aa5c6h@mail.gmail.com> <17412.24885.59516.767056@zapata.pink> Message-ID: <17412.39035.398071.632293@zapata.pink> Andrew Haley writes: > Garry Harthill writes: > > top - 14:24:28 up 5 days, 3:41, 5 users, load average: 3.78, 3.61, 3.27 > > Tasks: 117 total, 1 running, 116 sleeping, 0 stopped, 0 zombie > > Cpu(s): 57.0% us, 10.3% sy, 0.0% ni, 31.1% id, 1.3% wa, 0.3% hi, 0.0% si > > Mem: 1027288k total, 1002144k used, 25144k free, 39564k buffers > > Swap: 1020116k total, 940k used, 1019176k free, 405756k cached > > > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > > 13132 garry 15 0 966m 213m 37m S 50.6 21.3 227:27.00 gij > > > > 213mb memory and 50% CPU seems a bit excessive. > > > > azureus-2.4.0.0-0.20060209cvs_1.fc5 > > glib-java-0.2.3-1.2 > > cairo-java-1.0.2-0.2 > > libgconf-java-2.12.1-2.2 > > libgtk-java-2.8.3-1.2 > > java-1.4.2-gcj-compat-1.4.2.0-40jpp_80rh > > > > Anyone else seeing this? > > When you start azureus, use 'gij -verbose:class'. See if any of the > classes are loaded 'bytecode'. It looks like this guess was wrong. The fact that others are seeing degraded functionality as well as degraded performancew suggests that something major is wrong. Andrew. From tibbs at math.uh.edu Tue Feb 28 20:00:45 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 28 Feb 2006 14:00:45 -0600 Subject: rawhide report: 20060227 changes - gtk2 circular dep In-Reply-To: <44048A68.40209@math.unl.edu> (Rex Dieter's message of "Tue, 28 Feb 2006 11:37:44 -0600") References: <200602270817.k1R8HK4Q008251@porkchop.devel.redhat.com> <1141146739.7702.41.camel@xpc.home.erwinrol.com> <44048636.9080502@cora.nwra.com> <44048A68.40209@math.unl.edu> Message-ID: Perhaps gtk-update-icon-cache should call itself when it is installed. That way any icon packs that were installed before it will be cached, and any that are installed after it will invoke it. (Assuming that everything which installs an icon uses the recommended %post scriptlet.) - J< From rdieter at math.unl.edu Tue Feb 28 20:21:09 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 28 Feb 2006 14:21:09 -0600 Subject: rawhide report: 20060227 changes - gtk2 circular dep In-Reply-To: References: <200602270817.k1R8HK4Q008251@porkchop.devel.redhat.com> <1141146739.7702.41.camel@xpc.home.erwinrol.com> <44048636.9080502@cora.nwra.com> <44048A68.40209@math.unl.edu> Message-ID: <4404B0B5.4050805@math.unl.edu> Jason L Tibbitts III wrote: > Perhaps gtk-update-icon-cache should call itself when it is > installed. That way any icon packs that were installed before it will > be cached, and any that are installed after it will invoke it. > (Assuming that everything which installs an icon uses the recommended > %post scriptlet.) Then we are in agreement: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170335#c2 -- Rex From gianluca.cecchi at gmail.com Tue Feb 28 21:20:41 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Tue, 28 Feb 2006 22:20:41 +0100 Subject: gphoto2 problem: usb access for non root users In-Reply-To: <561c252c0602272305j3ce08b12o@mail.gmail.com> References: <561c252c0601311402s2dfa06d3s@mail.gmail.com> <200602241919.34962.jbarnes@virtuousgeek.org> <20060227171355.GA31836@devserv.devel.redhat.com> <200602270945.03846.jbarnes@virtuousgeek.org> <561c252c0602272305j3ce08b12o@mail.gmail.com> Message-ID: <561c252c0602281320v7254d1dap@mail.gmail.com> 2006/2/28, Gianluca Cecchi : > Today when @home I can test with kde too, to see pop ups. tried with updates at 18th of february and logged in with kde as de. After connecting my camera (that uses ptp protocol) I get: - window popup saying: new medium has been detected what do you want to do? - I select "open in new window" - konqueror opens positioned in system:/media/camera - it seems very slow reading contents from digicamera it detects only 4 items at the beginning showing 4% progress at bottom right and then finds anything different from four files store_00010001 store_00020001 about.txt summary.txt inside kde konsole as normal user I correctly get: [gcecchi at fedora ~]$ gphoto2 --auto-detect Model Port ---------------------------------------------------------- Kodak CX7525 usb: Kodak CX7525 usb:002,002 so it seems to me a problem in konqueror plugin (which one?) to read digicamera contents. Or perhaps you have problems only if ptp protocol is used... and digicameras that use the other protocol (usb mass storage aka scsi over usb) that gets the storage detected as scsi disks work better in konqueror plugin... BTW what are secs for your digicamera? To debug, try install digikam from extras and see if it works. Or use the default gnome application for this (don't remember its name) inside kde de. See also gphoto2 supported cameras list, to match yours: http://www.gphoto.org/proj/libgphoto2/support.php HIH, Gianluca From nicolas.mailhot at laposte.net Tue Feb 28 22:46:35 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 28 Feb 2006 23:46:35 +0100 Subject: rawhide report: 20060227 changes - gtk2 circular dep In-Reply-To: References: <200602270817.k1R8HK4Q008251@porkchop.devel.redhat.com> <1141146739.7702.41.camel@xpc.home.erwinrol.com> <44048636.9080502@cora.nwra.com> <44048A68.40209@math.unl.edu> Message-ID: <1141166796.2543.0.camel@rousalka.dyndns.org> Le mardi 28 f?vrier 2006 ? 14:00 -0600, Jason L Tibbitts III a ?crit : > Perhaps gtk-update-icon-cache should call itself when it is > installed. That way any icon packs that were installed before it will > be cached, and any that are installed after it will invoke it. > (Assuming that everything which installs an icon uses the recommended > %post scriptlet.) That's how the font scripts work -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: